Date: Thu, 23 Feb 2017 11:20:15 +0000 From: <Hartmut.Brandt@dlr.de> To: <dim@FreeBSD.org> Cc: <current@freebsd.org> Subject: RE: int128_t and uint128_t typeinfo Message-ID: <611243783F62AF48AFB07BC25FA4B1061CEED2E2@DLREXMBX01.intra.dlr.de> In-Reply-To: <201471EF-D383-49C0-B03B-64B91BAA4F0A@FreeBSD.org> References: <alpine.BSF.2.20.1702211347050.82742@KNOP-BEAGLE.kn.op.dlr.de> <54594A33-C1DE-4491-8AD2-04E354EC5FAE@FreeBSD.org> <3EBF6862-8DEC-4F96-9C95-78FEE5242A6C@FreeBSD.org> <611243783F62AF48AFB07BC25FA4B1061CEECBB6@DLREXMBX01.intra.dlr.de> <201471EF-D383-49C0-B03B-64B91BAA4F0A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Now that appears to work.
Thanks,
harti
-----Original Message-----
From: Dimitry Andric [mailto:dim@FreeBSD.org]=20
Sent: Wednesday, February 22, 2017 7:49 PM
To: Brandt, Hartmut
Cc: current@freebsd.org
Subject: Re: int128_t and uint128_t typeinfo
I had to commit a follow-up fix in r314104: when C++ names are used in the =
version script, they have to be surrounded by an extern "C++" {} block, oth=
erwise the symbols end up as locals in the final library, and thus get stri=
pped out of the installed version.
-Dimitry
On 22 Feb 2017, at 16:19, Hartmut.Brandt@dlr.de wrote:
>=20
> Looks like they are still not there. I've rebuilt world.
>=20
> nm -D -C /usr/lib/libcxxrt.so | grep 128
>=20
> should show me the symbols, right? It does not.
>=20
> harti
>=20
> -----Original Message-----
> From: Dimitry Andric [mailto:dim@FreeBSD.org]
> Sent: Tuesday, February 21, 2017 10:52 PM
> To: Brandt, Hartmut
> Cc: current@freebsd.org
> Subject: Re: int128_t and uint128_t typeinfo
>=20
> On 21 Feb 2017, at 18:26, Dimitry Andric <dim@FreeBSD.org> wrote:
>>=20
>> On 21 Feb 2017, at 13:48, Hartmut Brandt <hartmut.brandt@dlr.de> wrote:
>>>=20
>>> it looks like the typeinfo for __int128_t and __uint128_t is missing fr=
om our dynamically linked libcxxrt.
> ...
>> * We also need to add the typeinfo for __u?int128_t * and=20
>> __u?int128_t const *
>> * Maybe these should be under the CXXABI_2.0 version, since that is=20
>> where newer libstdc++ places them
>> * Maybe these should be dependent on whether the architecture=20
>> supports
>> 128 bit integers at all
>>=20
>> I need to think a bit on the above, then I'll commit a fix.
>=20
> Okay, can you please try r314061?
>=20
> -Dimitry
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?611243783F62AF48AFB07BC25FA4B1061CEED2E2>