From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 13:28:57 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DB4F58C for ; Sun, 27 Jan 2013 13:28:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id D4417FFA for ; Sun, 27 Jan 2013 13:28:56 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0RDSmHG089548 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Sun, 27 Jan 2013 13:28:50 GMT (envelope-from theraven@FreeBSD.org) From: David Chisnall Content-Type: multipart/signed; boundary="Apple-Mail=_0476F75C-ABFF-4943-A958-52F5DA5521EF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: C++ runtime version patch for testing Date: Sun, 27 Jan 2013 13:28:44 +0000 Message-Id: To: toolchain@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 13:28:57 -0000 --Apple-Mail=_0476F75C-ABFF-4943-A958-52F5DA5521EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, Here is a patch that, I believe, should fix the symbol version = mismatches between the runtime and the STL implementation. I have run = the exception tests from libcxxrt with this patch applied and: - libsupc++ & libstdc++ - libcxxrt & libstdc++ - libcxxrt & libc++ All tests pass for me now. Please let me know if there are any problems = with this, otherwise I'll aim to commit it today or tomorrow with a = 1-week MFC. David Index: gnu/lib/libsupc++/Version.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gnu/lib/libsupc++/Version.map (revision 245840) +++ gnu/lib/libsupc++/Version.map (working copy) @@ -142,6 +142,28 @@ _ZdaPvRKSt9nothrow_t; _ZdlPv; _ZdlPvRKSt9nothrow_t; + extern "C++" { + std::set_new_handler*; + std::set_terminate*; + std::set_unexpected*; + std::bad_alloc*; + + std::bad_alloc*; + std::bad_cast*; + std::exception*; + + "typeinfo for std::bad_alloc"; + "typeinfo for std::bad_cast"; + "typeinfo for std::exception"; + + "typeinfo name for std::bad_alloc"; + "typeinfo name for std::bad_cast"; + "typeinfo name for std::exception"; + + "vtable for std::bad_alloc"; + "vtable for std::bad_cast"; + "vtable for std::exception"; + }; }; =20 CXXABI_1.3.1 { Index: lib/libcxxrt/Version.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libcxxrt/Version.map (revision 245840) +++ lib/libcxxrt/Version.map (working copy) @@ -209,18 +209,7 @@ =20 "std::type_info::type_info(std::type_info const&)"; "std::type_info::type_info(std::type_info const&)"; - "std::type_info::~type_info()"; - "std::type_info::~type_info()"; - "std::type_info::~type_info()"; "std::type_info::operator=3D(std::type_info const&)"; - "std::unexpected()"; - "std::get_terminate()"; - "std::set_terminate(void (*)())"; - "std::get_unexpected()"; - "std::set_unexpected(void (*)())"; - "std::set_new_handler(void (*)())"; - "std::uncaught_exception()"; - "std::terminate()"; =20 =20 # Extensions @@ -243,70 +232,25 @@ CXXRT_1.0 { =20 extern "C++" { - "std::bad_cast::what() const"; - "std::bad_typeid::what() const"; - "std::bad_alloc::what() const"; - "std::exception::what() const"; "std::type_info::name() const"; "std::type_info::before(std::type_info const&) const"; "std::type_info::operator=3D=3D(std::type_info const&) const"; "std::type_info::operator!=3D(std::type_info const&) const"; - "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; - "std::bad_typeid::bad_typeid()"; - "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; - "std::bad_typeid::bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::operator=3D(std::bad_typeid const&)"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; - "std::bad_cast::~bad_cast()"; - "std::bad_cast::~bad_cast()"; - "std::bad_cast::~bad_cast()"; "std::bad_cast::operator=3D(std::bad_cast const&)"; - "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; - "std::bad_alloc::bad_alloc()"; - "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; - "std::bad_alloc::bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::operator=3D(std::bad_alloc const&)"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; - "std::exception::~exception()"; - "std::exception::~exception()"; - "std::exception::~exception()"; "std::exception::operator=3D(std::exception const&)"; =20 =20 - "vtable for std::bad_typeid"; - "vtable for std::bad_cast"; - "vtable for std::bad_alloc"; - "vtable for std::exception"; - "vtable for std::type_info"; - "typeinfo for std::bad_typeid"; - "typeinfo for std::bad_cast"; - "typeinfo for std::bad_alloc"; - "typeinfo for std::exception"; - "typeinfo for std::type_info"; - "typeinfo name for std::bad_typeid"; - "typeinfo name for std::bad_cast"; - "typeinfo name for std::bad_alloc"; - "typeinfo name for std::exception"; - "typeinfo name for std::type_info"; =20 - "std::type_info::__is_function_p() const"; - "std::type_info::__do_upcast(__cxxabiv1::__class_type_info = const*, void**) const"; - "std::type_info::__is_pointer_p() const"; =20 =20 - }; __cxa_allocate_dependent_exception; __cxa_current_primary_exception; @@ -317,6 +261,15 @@ =20 } CXXABI_1.3.1; =20 + +GLIBCXX_3.4.9 { + extern "C++" { + "std::bad_typeid::what() const"; + "std::bad_cast::what() const"; + "std::bad_alloc::what() const"; + }; +}; + GLIBCXX_3.4 { extern "C++" { "operator delete[](void*)"; @@ -327,5 +280,41 @@ "operator new[](unsigned long)"; "operator new(unsigned long)"; "operator new(unsigned long, std::nothrow_t const&)"; + + "std::unexpected()"; + "std::get_terminate()"; + "std::get_unexpected()"; + "std::uncaught_exception()"; + "std::terminate()"; + + "std::type_info::~type_info()"; + "std::bad_cast::~bad_cast()"; + "std::exception::~exception()"; + + std::set_new_handler*; + std::set_terminate*; + std::set_unexpected*; + std::exception*; + std::bad_alloc*; + std::bad_typeid*; + std::type_info*; + + "vtable for std::bad_alloc"; + "vtable for std::bad_cast"; + "vtable for std::bad_typeid"; + "vtable for std::exception"; + "vtable for std::type_info"; + + "typeinfo for std::bad_alloc"; + "typeinfo for std::bad_typeid"; + "typeinfo for std::exception"; + "typeinfo for std::bad_cast"; + "typeinfo for std::exception"; + "typeinfo for std::type_info"; + "typeinfo name for std::bad_typeid"; + "typeinfo name for std::bad_cast"; + "typeinfo name for std::exception"; + "typeinfo name for std::type_info"; + }; }; --Apple-Mail=_0476F75C-ABFF-4943-A958-52F5DA5521EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRBSuNAAoJEKx65DEEsqIdCfIP+gLdpwTPdLYLFwc4aeWU+dp1 SG9BviCrEDWOtJ5uPr1J5GCDoXv3b0fzZarufx6OZ/M2DmarB0PzG0ILrQQldlVI xSDBlFJmCV4nWzBuLLoVL1qf7JF75aRre85+iAiOnayW9kn6WvXFCsUYO0iZqpJg A864hMFmQmQUbQmUeT7nGD9zBz49Bh1XLByTGcey77OHDhngKvpKsNWaw+dYG8lf ZAOhKDQQaa5i4fbcd08UENYs/uVqIqP9D5PHQP4vzd0eh/IgX8oac6feh6pdIrHv uN6WUkS/DGj5Yc5yzdGCD62n5qhpudI3zV8a1wK2G8PYrh3of0XprCFC1hEyL3zh qJNNLOUJL61GLTNk2jBfoj0T/JTppuxeinf6E51N+bDxg1zuoc9D/MY5uD0iDAYG Cw8W+Ygo4xHoW8Wu+m6BUHCh/c4jKNrhebCC1qyq0tWjX5w3N3YAovADUueusaTc I+2uJgXuPfiUoHGLKd+MIkWqCPKlHCyXrU2VltwdWpyFD9Xz1N3OSJELibJJFCV3 mcUwmP7zESAJf7Fjlq9W1s4cYQgD06mhFmQpHS9G8ws7ipE/6fjYua5C76Fv3g// i64fmcQnWYjEReKZP8M0+7852QlT4UWYC5Gy4mGlpbdDWXyhiL2EB+fuvemxwKzK YKHpqhwo7RmyDFvVwnOP =Ek76 -----END PGP SIGNATURE----- --Apple-Mail=_0476F75C-ABFF-4943-A958-52F5DA5521EF-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 15:03:18 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 29F75F28; Sun, 27 Jan 2013 15:03:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADD7642; Sun, 27 Jan 2013 15:03:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0RF3Dbx025005; Sun, 27 Jan 2013 17:03:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0RF3Dbx025005 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0RF3DNG025004; Sun, 27 Jan 2013 17:03:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Jan 2013 17:03:13 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: C++ runtime version patch for testing Message-ID: <20130127150313.GM2522@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S/ANZfAJ/3KdLSz0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:03:18 -0000 --S/ANZfAJ/3KdLSz0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 27, 2013 at 01:28:44PM +0000, David Chisnall wrote: > Hi All, >=20 > Here is a patch that, I believe, should fix the symbol version mismatches= between the runtime and the STL implementation. I have run the exception = tests from libcxxrt with this patch applied and: >=20 > - libsupc++ & libstdc++ > - libcxxrt & libstdc++ > - libcxxrt & libc++ >=20 > All tests pass for me now. Please let me know if there are any problems = with this, otherwise I'll aim to commit it today or tomorrow with a 1-week = MFC. >=20 > David >=20 > Index: gnu/lib/libsupc++/Version.map > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gnu/lib/libsupc++/Version.map (revision 245840) > +++ gnu/lib/libsupc++/Version.map (working copy) > @@ -142,6 +142,28 @@ > _ZdaPvRKSt9nothrow_t; > _ZdlPv; > _ZdlPvRKSt9nothrow_t; > + extern "C++" { > + std::set_new_handler*; What are the symbols you assigning the version there ? I cannot find anything in the libstdc++.so export list which would match the line. > + std::set_terminate*; > + std::set_unexpected*; > + std::bad_alloc*; > + > + std::bad_alloc*; std::bad_alloc seems to be duplicated. Besides that, pristine libstdc++.so exports 'std::bad_alloc::what() const' at the GLIBCXX_3.4.9 namespace. You did this for the *::what()' from libcxxrt but not for the libsupc++. > + std::bad_cast*; > + std::exception*; > + > + "typeinfo for std::bad_alloc"; > + "typeinfo for std::bad_cast"; > + "typeinfo for std::exception"; > + > + "typeinfo name for std::bad_alloc"; > + "typeinfo name for std::bad_cast"; > + "typeinfo name for std::exception"; > + > + "vtable for std::bad_alloc"; > + "vtable for std::bad_cast"; > + "vtable for std::exception"; > + }; > }; > =20 > CXXABI_1.3.1 { > Index: lib/libcxxrt/Version.map > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libcxxrt/Version.map (revision 245840) > +++ lib/libcxxrt/Version.map (working copy) > @@ -209,18 +209,7 @@ > =20 > "std::type_info::type_info(std::type_info const&)"; > "std::type_info::type_info(std::type_info const&)"; > - "std::type_info::~type_info()"; > - "std::type_info::~type_info()"; > - "std::type_info::~type_info()"; > "std::type_info::operator=3D(std::type_info const&)"; [omitted] Do applications record the dependency on the libcxxrt directly, using the DT_NEEDED tag ? --S/ANZfAJ/3KdLSz0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBUGwAAoJEJDCuSvBvK1BIQcQAJJYvqkp7yN1E6yMdJ9CZHOh wXz6k77UMxuaEuQ/d0sdqKkwnKwZocrhG1i5pGctJ+kzSVOTBRL+pJsxB2MA/fK7 85tpFn2GtSwT4CGFsEpu2Ij71sh6fz1hsGEEM2nWhkZwF2zG9VM83Q67YaiBj4ee 0SRh7/JMlQWMsKGgeOiz8hTQkNJug2eb5SteKNy4kBCDB/9JNQTpMb6DFPofwWSY YsqBmmHMmhRQhpnNuX+1LU+qXUqs07WX0qISX8bDTgcrfMLeU55uGE5KhKkRWHYT qkWikhiXSh3TzNE+iHK3YJJr7D/vnWHjY6S+bhCkY1JyjgEo5aWfUutCZQan4c3n rlHcAXeUAGHqDMPMtFouQTgL9PgF2fhUzdSFV/s9V5HhF1JHhuEB6fpMKsMgX8ZM AckE2bJhUvOfKY320iH0p9UdwqyGxoT0Jwe0P3P3iq/4INzWuu8wm+OaQrIAqSBF 0yiF0J+Px91owTlzCXbQEu3q00SDiFuaG9DXigkuIM4Uu1XKpnqAMAxPWf/tpi0E lb8WbvGQ/oWeIaCE1ThJfuAAn+9SnA2HwNzcS85JkXYnakHKoIISYA+D/6SZCfkP VaiV+JBgOBJvTq2LCiIp/JtNbXHUYA7JaWKToq3P+QgfZc5hNhHIrL2EIUyVCE+E 5IQyZl8xnoi1Ts5g6sEe =5a59 -----END PGP SIGNATURE----- --S/ANZfAJ/3KdLSz0-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 15:18:00 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 427EF2C7 for ; Sun, 27 Jan 2013 15:18:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 01F6B6C4 for ; Sun, 27 Jan 2013 15:17:59 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0RFHv6c089878 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 27 Jan 2013 15:17:58 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: C++ runtime version patch for testing Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0D58810B-063C-4B2B-BE28-DAC66DF05352"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130127150313.GM2522@kib.kiev.ua> Date: Sun, 27 Jan 2013 15:17:51 +0000 Message-Id: <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> References: <20130127150313.GM2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:18:00 -0000 --Apple-Mail=_0D58810B-063C-4B2B-BE28-DAC66DF05352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Jan 2013, at 15:03, Konstantin Belousov wrote: > On Sun, Jan 27, 2013 at 01:28:44PM +0000, David Chisnall wrote: >> + std::set_new_handler*; > What are the symbols you assigning the version there ? I cannot find > anything in the libstdc++.so export list which would match the line. std::set_new_handler(void (*)()) # objdump -T /usr/lib/libsupc++.so | c++filt | grep new_h 0000000000009010 __float128 DF .text 000000000000000e GLIBCXX_3.4 = std::set_new_handler(void (*)()) >> + std::set_terminate*; >> + std::set_unexpected*; >> + std::bad_alloc*; >> + >> + std::bad_alloc*; > std::bad_alloc seems to be duplicated. Thanks, removed. > Besides that, pristine libstdc++.so exports 'std::bad_alloc::what() = const' > at the GLIBCXX_3.4.9 namespace. You did this for the *::what()' from > libcxxrt but not for the libsupc++. Ooops. I wrote a script that checked for version mismatches, but for = some reason I missed this one. Running it again, it shows two = mismatches, both fixed in the new version of the diff. >> + std::bad_cast*; >> + std::exception*; >> + >> + "typeinfo for std::bad_alloc"; >> + "typeinfo for std::bad_cast"; >> + "typeinfo for std::exception"; >> + >> + "typeinfo name for std::bad_alloc"; >> + "typeinfo name for std::bad_cast"; >> + "typeinfo name for std::exception"; >> + >> + "vtable for std::bad_alloc"; >> + "vtable for std::bad_cast"; >> + "vtable for std::exception"; >> + }; >> }; >>=20 >> CXXABI_1.3.1 { >> Index: lib/libcxxrt/Version.map >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/libcxxrt/Version.map (revision 245840) >> +++ lib/libcxxrt/Version.map (working copy) >> @@ -209,18 +209,7 @@ >>=20 >> "std::type_info::type_info(std::type_info const&)"; >> "std::type_info::type_info(std::type_info const&)"; >> - "std::type_info::~type_info()"; >> - "std::type_info::~type_info()"; >> - "std::type_info::~type_info()"; >> "std::type_info::operator=3D(std::type_info const&)"; > [omitted] >=20 > Do applications record the dependency on the libcxxrt directly, > using the DT_NEEDED tag ? I don't believe so, they get it indirectly via libc++ or libstdc++. How = can I check? David Index: gnu/lib/libsupc++/Version.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gnu/lib/libsupc++/Version.map (revision 245840) +++ gnu/lib/libsupc++/Version.map (working copy) @@ -130,6 +130,13 @@ *; }; =20 +GLIBCXX_3.4.9 { + extern "C++" { + "std::bad_alloc::what() const"; + "std::bad_cast::what() const"; + }; +}; + GLIBCXX_3.4 { # operator new and new[] _Znai[jm]; @@ -142,6 +149,27 @@ _ZdaPvRKSt9nothrow_t; _ZdlPv; _ZdlPvRKSt9nothrow_t; + extern "C++" { + std::set_new_handler*; + std::set_terminate*; + std::set_unexpected*; + + std::bad_alloc*; + std::bad_cast*; + std::exception*; + + "typeinfo for std::bad_alloc"; + "typeinfo for std::bad_cast"; + "typeinfo for std::exception"; + + "typeinfo name for std::bad_alloc"; + "typeinfo name for std::bad_cast"; + "typeinfo name for std::exception"; + + "vtable for std::bad_alloc"; + "vtable for std::bad_cast"; + "vtable for std::exception"; + }; }; =20 CXXABI_1.3.1 { Index: lib/libcxxrt/Version.map =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libcxxrt/Version.map (revision 245840) +++ lib/libcxxrt/Version.map (working copy) @@ -209,18 +209,7 @@ =20 "std::type_info::type_info(std::type_info const&)"; "std::type_info::type_info(std::type_info const&)"; - "std::type_info::~type_info()"; - "std::type_info::~type_info()"; - "std::type_info::~type_info()"; "std::type_info::operator=3D(std::type_info const&)"; - "std::unexpected()"; - "std::get_terminate()"; - "std::set_terminate(void (*)())"; - "std::get_unexpected()"; - "std::set_unexpected(void (*)())"; - "std::set_new_handler(void (*)())"; - "std::uncaught_exception()"; - "std::terminate()"; =20 =20 # Extensions @@ -243,70 +232,25 @@ CXXRT_1.0 { =20 extern "C++" { - "std::bad_cast::what() const"; - "std::bad_typeid::what() const"; - "std::bad_alloc::what() const"; - "std::exception::what() const"; "std::type_info::name() const"; "std::type_info::before(std::type_info const&) const"; "std::type_info::operator=3D=3D(std::type_info const&) const"; "std::type_info::operator!=3D(std::type_info const&) const"; - "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; - "std::bad_typeid::bad_typeid()"; - "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; - "std::bad_typeid::bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::~bad_typeid()"; - "std::bad_typeid::operator=3D(std::bad_typeid const&)"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; - "std::bad_cast::~bad_cast()"; - "std::bad_cast::~bad_cast()"; - "std::bad_cast::~bad_cast()"; "std::bad_cast::operator=3D(std::bad_cast const&)"; - "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; - "std::bad_alloc::bad_alloc()"; - "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; - "std::bad_alloc::bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::~bad_alloc()"; - "std::bad_alloc::operator=3D(std::bad_alloc const&)"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; - "std::exception::~exception()"; - "std::exception::~exception()"; - "std::exception::~exception()"; "std::exception::operator=3D(std::exception const&)"; =20 =20 - "vtable for std::bad_typeid"; - "vtable for std::bad_cast"; - "vtable for std::bad_alloc"; - "vtable for std::exception"; - "vtable for std::type_info"; - "typeinfo for std::bad_typeid"; - "typeinfo for std::bad_cast"; - "typeinfo for std::bad_alloc"; - "typeinfo for std::exception"; - "typeinfo for std::type_info"; - "typeinfo name for std::bad_typeid"; - "typeinfo name for std::bad_cast"; - "typeinfo name for std::bad_alloc"; - "typeinfo name for std::exception"; - "typeinfo name for std::type_info"; =20 - "std::type_info::__is_function_p() const"; - "std::type_info::__do_upcast(__cxxabiv1::__class_type_info = const*, void**) const"; - "std::type_info::__is_pointer_p() const"; =20 =20 - }; __cxa_allocate_dependent_exception; __cxa_current_primary_exception; @@ -317,6 +261,15 @@ =20 } CXXABI_1.3.1; =20 + +GLIBCXX_3.4.9 { + extern "C++" { + "std::bad_typeid::what() const"; + "std::bad_cast::what() const"; + "std::bad_alloc::what() const"; + }; +}; + GLIBCXX_3.4 { extern "C++" { "operator delete[](void*)"; @@ -327,5 +280,41 @@ "operator new[](unsigned long)"; "operator new(unsigned long)"; "operator new(unsigned long, std::nothrow_t const&)"; + + "std::unexpected()"; + "std::get_terminate()"; + "std::get_unexpected()"; + "std::uncaught_exception()"; + "std::terminate()"; + + "std::type_info::~type_info()"; + "std::bad_cast::~bad_cast()"; + "std::exception::~exception()"; + + std::set_new_handler*; + std::set_terminate*; + std::set_unexpected*; + std::exception*; + std::bad_alloc*; + std::bad_typeid*; + std::type_info*; + + "vtable for std::bad_alloc"; + "vtable for std::bad_cast"; + "vtable for std::bad_typeid"; + "vtable for std::exception"; + "vtable for std::type_info"; + + "typeinfo for std::bad_alloc"; + "typeinfo for std::bad_typeid"; + "typeinfo for std::exception"; + "typeinfo for std::bad_cast"; + "typeinfo for std::exception"; + "typeinfo for std::type_info"; + "typeinfo name for std::bad_typeid"; + "typeinfo name for std::bad_cast"; + "typeinfo name for std::exception"; + "typeinfo name for std::type_info"; + }; }; --Apple-Mail=_0D58810B-063C-4B2B-BE28-DAC66DF05352 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRBUUgAAoJEKx65DEEsqIdyvMQAJoHt2mVRfJnA5AiTdu5KEVN OWIqLTL+oM8ANWzNUL6WdtZXTKCF+vTV90sRzrKR9xNujw3OBjVzxDIcU9I++rN/ p94/29J/aKiYrBmkBjkHHl5d2zZPIE8PHuQrBNfn7apsVbUn01Xz+F2gz9CQXbmJ VL4LRM1uap1dUtsAnTKJAfKyOFjNLyqMiRbrjhgDANzDI+OGBi/9tji0sQN3YbPk Njn7I1Z4jmB+iwFoWV8HoG/jrA8tAad8j4kNyACmuNv+SXceEYZ8dmoBsebBrVrD aX3ELbJsp3csnfdQ/SbPwAcXGhAP2tFcNyAkTrO7a1kApAkR8dvJKBO1285Iap4F UCWYW+uMI1cmVbNxb4Dt7Al54rAXluUGURv8QmHyBnzjnRP2YAktx6xSkVSVHmo9 9/A2fiUEGLtthF8QDqlD2I7Wi6AYc8zpkzIF6RRev5mHGGgUqS22cjuIw2TyA749 hwMkQM1EHNXj9aONDqk8nL5kv4yF5oRndYnAcUfrrWsD0fUnCOMDvGDi1wHgLosl 43iZxPeXLXlFoJIiN98vAN+4gHeqXbsqOQIVq7j80lhcYK0wwLqDfQBQGvc0/DsF nQ1k1azTNZnHIeqXFMTpEUixFdBUqi/0gIiQCDK/v/5Q5eHZUoe3U1YlGdB+3X+F 9Gi2nq5IKrd62yot2Znh =tA4m -----END PGP SIGNATURE----- --Apple-Mail=_0D58810B-063C-4B2B-BE28-DAC66DF05352-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 15:52:17 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93B7CB84; Sun, 27 Jan 2013 15:52:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DFE04816; Sun, 27 Jan 2013 15:52:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0RFq8aQ030244; Sun, 27 Jan 2013 17:52:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0RFq8aQ030244 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0RFq7Bj030243; Sun, 27 Jan 2013 17:52:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Jan 2013 17:52:06 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: C++ runtime version patch for testing Message-ID: <20130127155206.GN2522@kib.kiev.ua> References: <20130127150313.GM2522@kib.kiev.ua> <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5NVDATmc8A1f9nDP" Content-Disposition: inline In-Reply-To: <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:52:17 -0000 --5NVDATmc8A1f9nDP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: > On 27 Jan 2013, at 15:03, Konstantin Belousov wrote: >=20 > > On Sun, Jan 27, 2013 at 01:28:44PM +0000, David Chisnall wrote: > >> + std::set_new_handler*; > > What are the symbols you assigning the version there ? I cannot find > > anything in the libstdc++.so export list which would match the line. >=20 > std::set_new_handler(void (*)()) >=20 > # objdump -T /usr/lib/libsupc++.so | c++filt | grep new_h > 0000000000009010 __float128 DF .text 000000000000000e GLIBCXX_3.4 std= ::set_new_handler(void (*)()) Apparently c++filt from 2.23.1 binutils has bug, c++filt is not able to demangle the set_new_handler. >=20 > >> + std::set_terminate*; > >> + std::set_unexpected*; > >> + std::bad_alloc*; > >> + > >> + std::bad_alloc*; > > std::bad_alloc seems to be duplicated. >=20 > Thanks, removed. >=20 > > Besides that, pristine libstdc++.so exports 'std::bad_alloc::what() con= st' > > at the GLIBCXX_3.4.9 namespace. You did this for the *::what()' from > > libcxxrt but not for the libsupc++. >=20 > Ooops. I wrote a script that checked for version mismatches, but for som= e reason I missed this one. Running it again, it shows two mismatches, bot= h fixed in the new version of the diff. >=20 You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it seems. >=20 > >> + std::bad_cast*; > >> + std::exception*; > >> + > >> + "typeinfo for std::bad_alloc"; > >> + "typeinfo for std::bad_cast"; > >> + "typeinfo for std::exception"; > >> + > >> + "typeinfo name for std::bad_alloc"; > >> + "typeinfo name for std::bad_cast"; > >> + "typeinfo name for std::exception"; > >> + > >> + "vtable for std::bad_alloc"; > >> + "vtable for std::bad_cast"; > >> + "vtable for std::exception"; > >> + }; > >> }; > >>=20 > >> CXXABI_1.3.1 { > >> Index: lib/libcxxrt/Version.map > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- lib/libcxxrt/Version.map (revision 245840) > >> +++ lib/libcxxrt/Version.map (working copy) > >> @@ -209,18 +209,7 @@ > >>=20 > >> "std::type_info::type_info(std::type_info const&)"; > >> "std::type_info::type_info(std::type_info const&)"; > >> - "std::type_info::~type_info()"; > >> - "std::type_info::~type_info()"; > >> - "std::type_info::~type_info()"; > >> "std::type_info::operator=3D(std::type_info const&)"; > > [omitted] > >=20 > > Do applications record the dependency on the libcxxrt directly, > > using the DT_NEEDED tag ? >=20 > I don't believe so, they get it indirectly via libc++ or libstdc++. How = can I check? >=20 Do readelf -d and look for the needed tags. If libcxxrt is not passed on the linker command line and not recorded as needed in the libc++/libstdc++, it should be fine. Your changes to libcxxrt obviously break the ABI, removing the symbols =66rom the version namespace, but my hope is that namespace for libcxxrt is actually not part of the _system_ ABI. Thus the question. --5NVDATmc8A1f9nDP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBU0mAAoJEJDCuSvBvK1BNUEP/irf94I6mfOmRqyRPSTCRfGI X16/h9E8fJ2wHNhft2++lORD74SM0P+RaRSPlYP0ff4HDotrE5vZ2kWDJuXSxMye lPlRQzWu0rvrJpZeh50SlJwltqd/Z8BD6oZq7EGWomXIrOndfqvipTAQfwWSFRIZ dLoHHFC8gt0BkTvSfTL3VER6az6bDbiwEy2Xpy26ShSsXq9iaDaXBpsLmIdLU79P KMmiEapnt4w8Uq+AZdgXtQQCYdP3XxN5/hw2Ptmiiulcd0pmDMdqnRoo+gtDkCSd TmEHhHFWxCVtN6o3CzAbcFTVuKMwDLJu4psF/6BVfm1Il3qnZTRB9WuE7Lvw2/Iy 2V+tFc5tNI0vZjCkvMewA2ZCqbORyUsBEKUrlUIdwbfXndmo1ItJYE6fJDOtlDNz q3/VkttNNxRvQwLjglYIMfLf9rJZk9Vq4KBpIxzPoXdGYE5/Epp9B3HXP34+8vVM K5XXWJzKaTXpah7bOl00gznbfTWMVcW2JHkpHVIxj3H1gEDS7JMqGgX9qVJU8NnO Q5raFcPh/J/mGI+FFqbmtyJzo2F/RUL1t9DZXc6o7VfitX/N6VRYxlbpzoZrjfy5 Z/ITyn+teGXqNQFxaO1RlBcyRmJiiE8GWPBmifqMH7nbmw901hNWLCKrCEKdpm9o hddOr8g641hmBBxRVU+4 =mU1A -----END PGP SIGNATURE----- --5NVDATmc8A1f9nDP-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 16:01:57 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68989FD for ; Sun, 27 Jan 2013 16:01:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2D30388B for ; Sun, 27 Jan 2013 16:01:56 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0RG1sS5090026 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 27 Jan 2013 16:01:56 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: C++ runtime version patch for testing Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_85DC9841-CC71-49AA-B83E-2E1887D1BE7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130127155206.GN2522@kib.kiev.ua> Date: Sun, 27 Jan 2013 16:01:48 +0000 Message-Id: <864783A2-E48D-49A6-AD3E-6EABE6EB5313@FreeBSD.org> References: <20130127150313.GM2522@kib.kiev.ua> <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> <20130127155206.GN2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:01:57 -0000 --Apple-Mail=_85DC9841-CC71-49AA-B83E-2E1887D1BE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: > On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: >=20 > Apparently c++filt from 2.23.1 binutils has bug, c++filt is > not able to demangle the set_new_handler. I'm using the one from head, which may be the elftoolchain project one? = It seems to be missing a man page... > You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it > seems. Added > Do readelf -d and look for the needed tags. If libcxxrt > is not passed on the linker command line and not recorded as needed > in the libc++/libstdc++, it should be fine. 0x0000000000000001 (NEEDED) Shared library: [libcxxrt.so.1] This is with something compiled with -stdlib=3Dlibc++. It seems the = (NEEDED) is there even if I compile with clang -lc++, instead of = clang++, so the linker is adding it via the indirect dependency? Or = does it show up because libc++ has that line too? > Your changes to libcxxrt obviously break the ABI, removing the symbols > from the version namespace, but my hope is that namespace for libcxxrt > is actually not part of the _system_ ABI. Thus the question. I'm okay with breaking the libcxxrt ABI at this point. libc++ is not = part of the standard install, and is there for testing in 9.1. libcxxrt = isn't linked against anything unless you use libc++ (or libstdc++ and a = line in libmap.conf) so nothing non-experimental should use it. For = 9.2, I'd like to have an ABI that we can support long term. David= --Apple-Mail=_85DC9841-CC71-49AA-B83E-2E1887D1BE7D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRBU9tAAoJEKx65DEEsqIdffgQAJ4+khCb0NKqnx69ZPThOwAI ++V1Mw5ZnB7noe9K53ndV5Pt8zjLMgLDC33SoDD6O2IWpzIS2sUFUXCcYpM8TvFb oVuIYTTKsQ62yYMBPMKluDhwa23I9BvNlt3VlKE2AnIaNOiLHfUwghadZj/rWCCY vGVNcu63RVAjrXoH/hBcu7NgoEC0WS+8yv3MnnIRdhpvHysFPS11KDmqQVRD2/d0 XScLrnMt9x4ZKVAZDMIZtBrnxGbxeRgvq83IymZdEwVbK+rXXnOokerDd5ZbP7PY GhQyVTszN/Voat9mJzif198fk9r0qBeR7OvVpVQ686urBrmmbFO+c7wAu7LEhuvq OCd2UnCunD0+vtou8+AWsg3YIIE75IsSOjOoUbs+/MafYZbyAzs08MxA2xdlfNG3 3929Pbdmfq+yJ54/jU730w2AFYUiASFPSdwam8ZROE374/MAiJ8EUqF8Jefi1rvV PSTV3EsWuvkyP47A775XTOE7oXUPwq3nMhJLDDmxR7EVVlM/uFgfdc7IiE0x3rQF CfJQ59KDG8uosiEWs2NytP926/O1bEOK2jHRYyPmNQ3N6YCmV7hQo4FFoG7vx4qp F4IzXJU8fieHcYViOfoMhwPIteHsNxa/5zqrqup+1oHnq+9eH5OLqSrjTjS0g9qq q7rkyL1nDQUEFCuvoqSo =LPgt -----END PGP SIGNATURE----- --Apple-Mail=_85DC9841-CC71-49AA-B83E-2E1887D1BE7D-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 27 16:16:00 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 942AB8D8; Sun, 27 Jan 2013 16:16:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E3A20968; Sun, 27 Jan 2013 16:15:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0RGFpHw032884; Sun, 27 Jan 2013 18:15:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0RGFpHw032884 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0RGFpGJ032883; Sun, 27 Jan 2013 18:15:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 27 Jan 2013 18:15:51 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: C++ runtime version patch for testing Message-ID: <20130127161551.GO2522@kib.kiev.ua> References: <20130127150313.GM2522@kib.kiev.ua> <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> <20130127155206.GN2522@kib.kiev.ua> <864783A2-E48D-49A6-AD3E-6EABE6EB5313@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sv7CUYPyUbxygwr6" Content-Disposition: inline In-Reply-To: <864783A2-E48D-49A6-AD3E-6EABE6EB5313@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:16:00 -0000 --sv7CUYPyUbxygwr6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 27, 2013 at 04:01:48PM +0000, David Chisnall wrote: > On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: >=20 > > On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: > >=20 > > Apparently c++filt from 2.23.1 binutils has bug, c++filt is > > not able to demangle the set_new_handler. >=20 > I'm using the one from head, which may be the elftoolchain project one? = It seems to be missing a man page... >=20 In head, the c++ demangler is coming from either binutils or gcc copy of libiberty. I did not looked which one is selected. > > You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it > > seems. >=20 > Added >=20 > > Do readelf -d and look for the needed tags. If libcxxrt > > is not passed on the linker command line and not recorded as needed > > in the libc++/libstdc++, it should be fine. >=20 > 0x0000000000000001 (NEEDED) Shared library: [libcxxrt.so.1] >=20 > This is with something compiled with -stdlib=3Dlibc++. It seems the > (NEEDED) is there even if I compile with clang -lc++, instead of > clang++, so the linker is adding it via the indirect dependency? Or > does it show up because libc++ has that line too? > Until recently, the default behaviour of the ELF linker was to record all second order needed libraries (i.e. libraries needed by a library specified on the linker command line) in the final link result. This is controllable with --copy-dt-needed-entries linker flag and recently the default were flipped to --no-copy. > > Your changes to libcxxrt obviously break the ABI, removing the symbols > > from the version namespace, but my hope is that namespace for libcxxrt > > is actually not part of the _system_ ABI. Thus the question. >=20 > I'm okay with breaking the libcxxrt ABI at this point. libc++ is > not part of the standard install, and is there for testing in 9.1. > libcxxrt isn't linked against anything unless you use libc++ (or > libstdc++ and a line in libmap.conf) so nothing non-experimental > should use it. For 9.2, I'd like to have an ABI that we can support > long term. > You might be okay with ABI breakage, but the project is not. Having ABI breakage on the stable branch is very unfortunate both =66rom the technical and PR points of view. You should consider using =2Egnu.warning. section or some other mechanism to explicitely warn about using libcxxrt begin unsupported, or better, remove it from the stable branch. --sv7CUYPyUbxygwr6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBVK2AAoJEJDCuSvBvK1B12oP/A/H9RBafEPzn/Msb0Dffd82 6ZjHniGBNITti19oMTsyVG5LwlBkrp42EQta+54jf9dMXVXnmJJODt20gRTmuMQE ngQTb1nS1Cm6dENO8b2M2hnvTg+NeIM1tjaqgT5Klg8D36Z96mhIrMfWjoQaCmqz K9a00TQz63QeNZbv/1wLX8gLtiUK0k2z6eyMExuy18PAYBOXziAvW7JAUjF9FMZ8 KjMJXLYgcc25KDToJdtbno421TbM8H6iQkEuVTC4oGR2DWQIGHRQ+YBFmRbCzQpK 8OV/ADSzACFjSUDDm+rLxpAHsjXVTELwJmhQA0W+PgsmBZ0tvGPvg4uxVIj4ss2q rrZp0kPJHXvViA8d3MDxYUgIv5o3kPs1hNBdvreiv0496woBU7+jK34418cGlKg0 4XCEkQQP3eQE/y46/kMGQvnAWS8AjQ9U/eD5Gft458KB+QQP3Nhhkq3eSppWWVZx VdZFXlZTW4fsv5INutnF7L4VWQwLvRKHGCBQBJOxbMOKbccMzWOT+/7ybj0FLpne S/aUXFZhzN5QZ4pTz64dMBGRPTZYeiH2STdmGIEHYWdF/5ftmkXp43lGnOOBX3c9 qSipxZ9cSO0yp39ufLhXcImcPZRYoqeSxNNyO89PErH/zs+lT6j2n0A6GnU3Awov QJGHSe4xSWxl0uKtCULI =iVsy -----END PGP SIGNATURE----- --sv7CUYPyUbxygwr6-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 28 07:26:57 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE3DF888; Mon, 28 Jan 2013 07:26:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1D15AE14; Mon, 28 Jan 2013 07:26:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0S7QnwZ031227; Mon, 28 Jan 2013 09:26:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0S7QnwZ031227 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0S7Qn1b031226; Mon, 28 Jan 2013 09:26:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 28 Jan 2013 09:26:49 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: C++ runtime version patch for testing Message-ID: <20130128072649.GR2522@kib.kiev.ua> References: <20130127150313.GM2522@kib.kiev.ua> <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> <20130127155206.GN2522@kib.kiev.ua> <864783A2-E48D-49A6-AD3E-6EABE6EB5313@FreeBSD.org> <20130127161551.GO2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kZbKUxA05I8F9C5i" Content-Disposition: inline In-Reply-To: <20130127161551.GO2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 07:26:57 -0000 --kZbKUxA05I8F9C5i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 27, 2013 at 06:15:51PM +0200, Konstantin Belousov wrote: > On Sun, Jan 27, 2013 at 04:01:48PM +0000, David Chisnall wrote: > > On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: > >=20 > > > On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: > > >=20 > > > Apparently c++filt from 2.23.1 binutils has bug, c++filt is > > > not able to demangle the set_new_handler. > >=20 > > I'm using the one from head, which may be the elftoolchain project one?= It seems to be missing a man page... > >=20 > In head, the c++ demangler is coming from either binutils or gcc copy > of libiberty. I did not looked which one is selected. >=20 > > > You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it > > > seems. > >=20 > > Added > >=20 > > > Do readelf -d and look for the needed tags. If libcxxrt > > > is not passed on the linker command line and not recorded as needed > > > in the libc++/libstdc++, it should be fine. > >=20 > > 0x0000000000000001 (NEEDED) Shared library: [libcxxrt.so.1] > >=20 > > This is with something compiled with -stdlib=3Dlibc++. It seems the > > (NEEDED) is there even if I compile with clang -lc++, instead of > > clang++, so the linker is adding it via the indirect dependency? Or > > does it show up because libc++ has that line too? > > > Until recently, the default behaviour of the ELF linker was to record > all second order needed libraries (i.e. libraries needed by a library > specified on the linker command line) in the final link result. This is > controllable with --copy-dt-needed-entries linker flag and recently > the default were flipped to --no-copy. >=20 >=20 > > > Your changes to libcxxrt obviously break the ABI, removing the symbols > > > from the version namespace, but my hope is that namespace for libcxxrt > > > is actually not part of the _system_ ABI. Thus the question. > >=20 > > I'm okay with breaking the libcxxrt ABI at this point. libc++ is > > not part of the standard install, and is there for testing in 9.1. > > libcxxrt isn't linked against anything unless you use libc++ (or > > libstdc++ and a line in libmap.conf) so nothing non-experimental > > should use it. For 9.2, I'd like to have an ABI that we can support > > long term. > > > You might be okay with ABI breakage, but the project is not. > Having ABI breakage on the stable branch is very unfortunate both > from the technical and PR points of view. You should consider using > .gnu.warning. section or some other mechanism to explicitely warn > about using libcxxrt begin unsupported, or better, remove it from > the stable branch. I noted one more thing to verify. Shouldn't the GLIBCXX_3.4.9 version inherit from the GLIBCXX_3.4, both for libsupc++ and libcxxrt ? I cannot verify the stock libstdc++ right now, but I suspect that namespace is inherited, and this must be fixed before the commit, if true. --kZbKUxA05I8F9C5i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBig5AAoJEJDCuSvBvK1BCTIP/jXnEUZAiS/m9xsBaj/h4eJu 8WVjhi1WnXYvykgbiJ3UO6f4ETWE3+FhnqgjLH5mR06h/0ai4CY1v3x6VLrH2Gu8 wuL/W7uau/pm+yUwB8o3R97odsSzk2+zgF9M8M5m58NAfjxrrs6fzJ4bXXJuGPDR z7b9/PUBMQa2Lft+gI08bwDFYtKVh+/NXI5rBhb73+WX3lciBOMYtUnPO3z+eXlW jiW0HWcYHRntcje7qZeoRhzaNmglrrPGXm2uEzcioS5XtxeEyUXgMorpCgscpXPG qvzw4ofURI4Ergz0sH2JABeKcT8l+IldU0hLCQ0fd4C/1nl8YZu7OqrVjXrSauML D/0ByvBrEFr51N+vVtC3kn6lqA5Guw39xHgD3RDXx9V90wTKJsn8eyifxgUGq2sr UOtqGd3U0ZCLvHjQzrVj4YdGpKao88PPC4uGaWnjkSB2lzRYfKYR53aMBOkI1GQj vB+eqUOFIvKMV0cCJl8eDIQDaiAesCMbSOmH/19Mg39Wqo1uBsNSP2PjeJCChK3g 9nCOnI6t4JMKg6/kjI7hGxWrLDpraoY+vh5L84cljVphvpa1paxoIOtUYmhetLTZ 8JT2f72vI4JFpSd1uRAJTPwe+V1YOlDG8IMqnF8HUsMNRHqyU+IDPftkRRrxm2pI /RWlFcFk/Ui8+CMH2vpr =bAWv -----END PGP SIGNATURE----- --kZbKUxA05I8F9C5i-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 28 15:12:01 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58B949F6 for ; Mon, 28 Jan 2013 15:12:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 890DE205 for ; Mon, 28 Jan 2013 15:11:59 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA02144 for ; Mon, 28 Jan 2013 17:11:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5106953E.2020907@FreeBSD.org> Date: Mon, 28 Jan 2013 17:11:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: toolchain@FreeBSD.org Subject: base gcc and _GLIBCXX_USE_C99 X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:12:01 -0000 Guys, I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from , , , , and can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ Because of this undef there is no e.g. std::strtoll(). Ditto for other things in stdlib.h. -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Thu Jan 31 23:03:41 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5645BEFC for ; Thu, 31 Jan 2013 23:03:41 +0000 (UTC) (envelope-from yamayan@kbh.biglobe.ne.jp) Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [IPv6:2001:260:401:16::1]) by mx1.freebsd.org (Postfix) with ESMTP id D55E79A2 for ; Thu, 31 Jan 2013 23:03:40 +0000 (UTC) Received: from vc-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (shby/5910021009) with SMTP id r0VN3c3g031721 for ; Fri, 1 Feb 2013 08:03:38 +0900 Received: from smtp-gw.biglobe.ne.jp ([172.21.56.80]) by vc-gw.biglobe.ne.jp (kbkr/0716090908) with ESMTP id r0VN3cGa031826 for ; Fri, 1 Feb 2013 08:03:38 +0900 X-Biglobe-Sender: Received: from [192.168.0.100] ([27.83.60.20]) by smtp-gw.biglobe.ne.jp id IAAIAC153810; Fri, 01 Feb 2013 08:03:38 +0900 (JST) Message-ID: <510AF84C.2080702@kbh.biglobe.ne.jp> Date: Fri, 01 Feb 2013 08:03:40 +0900 From: Yamaya Takashi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: toolchain@freebsd.org Subject: [patch]r246028, libcxxrt's Version.map is broken Content-Type: multipart/mixed; boundary="------------010802080507030301060203" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:03:41 -0000 This is a multi-part message in MIME format. --------------010802080507030301060203 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed. libcxxrt's Version.map is broken, because some needed symbols are removed. --------------010802080507030301060203 Content-Type: text/x-patch; name="vmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vmap.patch" Index: lib/libcxxrt/Version.map =================================================================== --- lib/libcxxrt/Version.map (revision 246142) +++ lib/libcxxrt/Version.map (working copy) @@ -208,7 +208,6 @@ "typeinfo name for __cxxabiv1::__vmi_class_type_info"; "std::type_info::type_info(std::type_info const&)"; - "std::type_info::type_info(std::type_info const&)"; "std::type_info::operator=(std::type_info const&)"; @@ -238,19 +237,17 @@ "std::type_info::operator!=(std::type_info const&) const"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; - "std::bad_cast::bad_cast(std::bad_cast const&)"; - "std::bad_cast::bad_cast()"; "std::bad_cast::operator=(std::bad_cast const&)"; + "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; + "std::bad_typeid::bad_typeid()"; + "std::bad_typeid::operator=(std::bad_typeid const&)"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; - "std::exception::exception(std::exception const&)"; - "std::exception::exception()"; "std::exception::operator=(std::exception const&)"; + "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; + "std::bad_alloc::bad_alloc()"; + "std::bad_alloc::operator=(std::bad_alloc const&)"; - - - - }; __cxa_allocate_dependent_exception; __cxa_current_primary_exception; @@ -282,13 +279,12 @@ "std::type_info::~type_info()"; "std::bad_cast::~bad_cast()"; "std::exception::~exception()"; + "std::bad_alloc::~bad_alloc()"; std::set_new_handler*; std::set_terminate*; std::set_unexpected*; std::exception*; - std::bad_alloc; - std::bad_typeid; std::type_info*; "vtable for std::bad_alloc"; @@ -299,10 +295,10 @@ "typeinfo for std::bad_alloc"; "typeinfo for std::bad_typeid"; - "typeinfo for std::exception"; "typeinfo for std::bad_cast"; "typeinfo for std::exception"; "typeinfo for std::type_info"; + "typeinfo name for std::bad_alloc"; "typeinfo name for std::bad_typeid"; "typeinfo name for std::bad_cast"; "typeinfo name for std::exception"; --------------010802080507030301060203-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 08:37:15 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85D46650 for ; Fri, 1 Feb 2013 08:37:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5C706342 for ; Fri, 1 Feb 2013 08:37:15 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r118bCVc015947 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 08:37:14 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: [patch]r246028, libcxxrt's Version.map is broken Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: David Chisnall In-Reply-To: <510AF84C.2080702@kbh.biglobe.ne.jp> Date: Fri, 1 Feb 2013 08:37:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <106C8345-AE40-48DE-A083-7C6C858F45A2@FreeBSD.org> References: <510AF84C.2080702@kbh.biglobe.ne.jp> To: Yamaya Takashi X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 08:37:15 -0000 Looks good to me. I probably won't have time to do adequate testing = until next week (just about to leave for FOSDEM), but I'm perfectly = happy for someone else to do it before then. David On 31 Jan 2013, at 23:03, Yamaya Takashi wrote: > Hi >=20 > After r246028, make buildworld with -stdlib=3Dlibc++ -std=3Dc++11 is = failed. > libcxxrt's Version.map is broken, because some needed symbols are = removed. >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 13:01:36 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C49C7E03; Fri, 1 Feb 2013 13:01:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B25D7354; Fri, 1 Feb 2013 13:01:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA19552; Fri, 01 Feb 2013 15:01:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510BBCAD.3070705@FreeBSD.org> Date: Fri, 01 Feb 2013 15:01:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: toolchain@FreeBSD.org Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> In-Reply-To: <5106953E.2020907@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:01:36 -0000 [ping] on 28/01/2013 17:11 Andriy Gapon said the following: > > Guys, > > I wonder why the following is the case for the base gcc. > /usr/include/c++/4.2/bits/c++config.h: > > /* Define if C99 functions or macros from , , , > , and can be used or exposed. */ > /* #undef _GLIBCXX_USE_C99 */ > > Because of this undef there is no e.g. std::strtoll(). > Ditto for other things in stdlib.h. > -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 13:08:24 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F9C6298; Fri, 1 Feb 2013 13:08:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id EEE9E3F2; Fri, 1 Feb 2013 13:08:23 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6CC2B5C5A; Fri, 1 Feb 2013 14:08:22 +0100 (CET) Message-ID: <510BBE48.4070101@FreeBSD.org> Date: Fri, 01 Feb 2013 14:08:24 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Andriy Gapon , toolchain@FreeBSD.org Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> In-Reply-To: <510BBCAD.3070705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:08:24 -0000 On 2013-02-01 14:01, Andriy Gapon wrote: > on 28/01/2013 17:11 Andriy Gapon said the following: >> I wonder why the following is the case for the base gcc. >> /usr/include/c++/4.2/bits/c++config.h: >> >> /* Define if C99 functions or macros from , , , >> , and can be used or exposed. */ >> /* #undef _GLIBCXX_USE_C99 */ >> >> Because of this undef there is no e.g. std::strtoll(). >> Ditto for other things in stdlib.h. Maybe this support can't be enabled, because we don't expose all the required functions yet? Or maybe it is just something that was committed years ago, and then forgotten. If we are sure that all the C99 functions libstdc++ requires are now available and working, I see no problem in turning on _GLIBCXX_USE_C99. From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 13:31:22 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A266590C; Fri, 1 Feb 2013 13:31:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8658D752; Fri, 1 Feb 2013 13:31:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA19836; Fri, 01 Feb 2013 15:31:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510BC3A7.5040405@FreeBSD.org> Date: Fri, 01 Feb 2013 15:31:19 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BBE48.4070101@FreeBSD.org> In-Reply-To: <510BBE48.4070101@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, freebsd-hackers X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:31:22 -0000 on 01/02/2013 15:08 Dimitry Andric said the following: > On 2013-02-01 14:01, Andriy Gapon wrote: >> on 28/01/2013 17:11 Andriy Gapon said the following: >>> I wonder why the following is the case for the base gcc. >>> /usr/include/c++/4.2/bits/c++config.h: >>> >>> /* Define if C99 functions or macros from , , , >>> , and can be used or exposed. */ >>> /* #undef _GLIBCXX_USE_C99 */ >>> >>> Because of this undef there is no e.g. std::strtoll(). >>> Ditto for other things in stdlib.h. > > Maybe this support can't be enabled, because we don't expose all the > required functions yet? Or maybe it is just something that was > committed years ago, and then forgotten. > > If we are sure that all the C99 functions libstdc++ requires are now > available and working, I see no problem in turning on _GLIBCXX_USE_C99. Having looked into the source code of a recent GCC I get an impression that this is a silliness on GCC's part (plus incompleteness of FreeBSD C99 support, it seems). cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined. Now looking at libstdc++-v3/acinclude.m4 we can see that there is a dedicated check "for ISO C99 support in ". That check sets variable glibcxx_cv_c99_stdlib. But, _GLIBCXX_USE_C99 is set only if all of glibcxx_cv_c99_math, glibcxx_cv_c99_complex, glibcxx_cv_c99_stdio, glibcxx_cv_c99_stdlib and glibcxx_cv_c99_wchar are set. So if glibcxx_cv_c99_stdlib is yes, but something like glibcxx_cv_c99_complex is no, then no std::strtoull for me. Not sure why GCC couldn't have a dedicated macro "_GLIBCXX_USE_C99_STDLIB" like e.g. _GLIBCXX_USE_C99_MATH that it does have. -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 14:03:00 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 10AF0E7D; Fri, 1 Feb 2013 14:03:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id C3F1E899; Fri, 1 Feb 2013 14:02:59 +0000 (UTC) Received: from [10.59.59.246] (ip-62-235-212-202.dsl.scarlet.be [62.235.212.202]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r11E2pRq017104 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 14:02:52 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: base gcc and _GLIBCXX_USE_C99 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <510BC3A7.5040405@FreeBSD.org> Date: Fri, 1 Feb 2013 14:02:53 +0000 Message-Id: <2F55F617-B12D-478D-8B24-3A705D6114BB@FreeBSD.org> References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> <510BBE48.4070101@FreeBSD.org> <510BC3A7.5040405@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org, Dimitry Andric , freebsd-hackers X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:03:00 -0000 --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Feb 2013, at 13:31, Andriy Gapon wrote: > cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is = defined. This is entirely consistent with the standard. strtoull() should only = be visible when compiling in C++11 mode, it is not part of C++98 / = C++03. David --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRC8sNAAoJEKx65DEEsqIdcCEQAIkmYIMH2vL8o7g4Hbjh2b+R kTMbdXJnZGTxVIAL2rJ/Aq7qw1FKRui8kyLFBaby258PPgD0lsD+GaTbiCHbmFVn FPjBValn+kwxxcp2jt68VG0Lt6jNPrP15CGL7AFkIhqL6mDI/lW1VZI2FPhTycS+ SaiTdSniruXeL7nN1jOti73y637Cm9MeGfnp1C2Hp0VhDKIcEvr0uDeotz+/FJd9 U6PkTaS2tvo4E2q3zCjh1IYVaAQhW1HoD/R7ATysE2yRmcqyFG5uTqqNashede1f h9D1YI4kg8OGzX5ZSJrOJ3S2dYiuLGQJa4XIMSV6RuvGvztVd2FF/Y5n0lcJxuEu brHur06bEbzG9GC/xtB8F+j/WHtG9VsfO6nTPdOSf3T1LNuO4P9xrfUJIwuQuYmz hEp0uYIqGc74cXw+BECiK+fGjf4l+gqWDXZ8SLrVKhk+iihz8PX+gurJVYXzUf5q G1zqIJNsgg3/dQUAuxXB2eXp0G3S9uYOVUOoIdRXESlVbIxUfp+7NaJnSs2KFvP1 6ehVUgsgbWnFQPUNMcr6v+uM0iLLtLgo1rMACKnfkwOxSC3TvC6yWa/roza7o72c tFN5rAFvK2k906f9onfX64uJ4Lq5/PPkD8Im/Np5tYjcBaWyl0yCHzpUll6BKzyH PrW4BjcebJtAPFKNCMMi =Ocnj -----END PGP SIGNATURE----- --Apple-Mail=_CE12C059-AE20-49B6-9CC3-FD2DD38B96FF-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 14:42:33 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7CA25E97 for ; Fri, 1 Feb 2013 14:42:33 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm24.bullet.mail.bf1.yahoo.com (nm24.bullet.mail.bf1.yahoo.com [98.139.212.183]) by mx1.freebsd.org (Postfix) with ESMTP id 24B97A60 for ; Fri, 1 Feb 2013 14:42:32 +0000 (UTC) Received: from [98.139.215.141] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 14:42:26 -0000 Received: from [98.139.213.5] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 14:42:26 -0000 Received: from [127.0.0.1] by smtp105.mail.bf1.yahoo.com with NNFMP; 01 Feb 2013 14:42:26 -0000 X-Yahoo-Newman-Id: 633365.80357.bm@smtp105.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Slk.wkIVM1kqGcsTrB7Ih0cvae3vau9htKu1mnqcgNFragz j2SFk1El3LfkFwG70Qri0AN3viD0t9YWEZRmmSkKUwmxeQhu2Pj_KhUHbs0y atJHsMJnmKysDTIM6SJd30J4txSW7TDaVmRcipmshRVCB6PkP5B2Bab7dRNJ CIa7DWgflM56dlhSZ45GigFft3B8IrD1rdBCjkpQJXwlowCuFc4umGVrI_2k z1TpADTuLAAemmdsDGDB9ZMr.P2M_Bib9F9.1EpPy_Lzl7xnI3.oMSq0O5ej cs686i1MIchnAgJcF1qx0edRwYMHwwgZpqFIn8N5cmkxOOngZFraPCxOheiV AUK1CLofJcp2auCfMLkYzp51JfWs4G.gUK8nHZ5LlQqmnoGt0hIe3tWI135a KXQI.psRwpIJG.Hcz65hjPGPCtrBqxeyRIt8xSxYQI0qLfNbjMaOY1bMqJDo UvR90KplL7N4QsbucuRJ2NPk5Vn6o79O9AxR0uxLuJSLdX4nfS9lqmDGAUfL vx9LRGvu99h9BdagD1OmA9oJVLRwLRxKM9MdJIg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp105.mail.bf1.yahoo.com with SMTP; 01 Feb 2013 06:42:26 -0800 PST Message-ID: <510BD454.2090306@FreeBSD.org> Date: Fri, 01 Feb 2013 09:42:28 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Subject: Re: [patch] crunchide breaks object files when using mclinker to do base system linking References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:42:33 -0000 On 01/25/2013 10:44, Erik Cederstrand wrote: > Hello list, > > On behalf of Pete Chou, I would like to ask for review, testing and hopefully commit help of this revised patch for crunchgen and crunchide which allows mclinker (http://code.google.com/p/mclinker/) to link the base system. In short, this patch is needed because crunchide is being overly strict about the section layout of an object file. > > Thanks, > Erik > Hello; Is there anyone working on this? This is not my area but it looks interesting so if no one else has complains I will run a buildworld over the weekend and commit it (assuming it doesn't break anything). Pedro. From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 14:46:26 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E052EFE for ; Fri, 1 Feb 2013 14:46:26 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm2-vm1.bullet.mail.ne1.yahoo.com (nm2-vm1.bullet.mail.ne1.yahoo.com [98.138.91.33]) by mx1.freebsd.org (Postfix) with ESMTP id 49479A94 for ; Fri, 1 Feb 2013 14:46:26 +0000 (UTC) Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 14:46:19 -0000 Received: from [98.138.226.58] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 14:46:19 -0000 Received: from [127.0.0.1] by smtp209.mail.ne1.yahoo.com with NNFMP; 01 Feb 2013 14:46:19 -0000 X-Yahoo-Newman-Id: 504818.98121.bm@smtp209.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vUyXYwAVM1lBx3u13JKqeIBhO911iSLFdUX7BF.uycEE_tm xlMsD16Ku0xRhtaRy6.JpB2gxdISuJ3uCyi0sZ9fwtKL4znNQGh7vq7U7jJT UABepTnJ8v1EWhAqpTvAGsYO4NmM766qzxMEdWqK65Uk9Ldgn.1Y_Tc28TbQ HMQl5gNyTW68D0_U39NFO4Iy6f5U_97glAcWi2EyaqDhY9Rmp89N0QKg.h_x YinOxQi5KRAvJMClKWAZyjnOQKPnHvI1.hLhJeXsvQ.2vLuAPg5YnJFhOxWd btprNdGT90tSSHh3bo27OJMDsWPeXho8qU5f.En3JXrDUyTvBUabI1SDXM_J kgn4QXtAS98let3Zfjrgiy18lhUsS9sJ3wxcue7SrlddbNIIJ9PbMvR8SDA1 8RkuUSLhSHbcsHxryOKrDh15gqf.EdlvUhWc1vFtsCSKE2uYZOYYW44Rby9U cUvUa0GaU2sk- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp209.mail.ne1.yahoo.com with SMTP; 01 Feb 2013 14:46:19 +0000 UTC Message-ID: <510BD53D.1070209@FreeBSD.org> Date: Fri, 01 Feb 2013 09:46:21 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: base gcc and _GLIBCXX_USE_C99 References: <5106953E.2020907@FreeBSD.org> <510BBCAD.3070705@FreeBSD.org> In-Reply-To: <510BBCAD.3070705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:46:26 -0000 Hello; On 02/01/2013 08:01, Andriy Gapon wrote: > [ping] > > on 28/01/2013 17:11 Andriy Gapon said the following: >> Guys, >> >> I wonder why the following is the case for the base gcc. >> /usr/include/c++/4.2/bits/c++config.h: >> >> /* Define if C99 functions or macros from , , , >> , and can be used or exposed. */ >> /* #undef _GLIBCXX_USE_C99 */ >> >> Because of this undef there is no e.g. std::strtoll(). >> Ditto for other things in stdlib.h. >> > I looked at this very briefly and it looks like it would fix a nasty issue we have been working around in OpenOffice. I suggest to enable it first on a gcc port though (it's tied to a configure flag, but don't remember which). Pedro. From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 1 15:28:34 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3EEA9D51 for ; Fri, 1 Feb 2013 15:28:34 +0000 (UTC) (envelope-from yamayan@kbh.biglobe.ne.jp) Received: from rcpt-expgw.biglobe.ne.jp (rcpt-expgw.biglobe.ne.jp [IPv6:2001:260:401:16::3]) by mx1.freebsd.org (Postfix) with ESMTP id BFC30D91 for ; Fri, 1 Feb 2013 15:28:33 +0000 (UTC) Received: from vc-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (shby/5910021009) with SMTP id r11FSVc8024739 for ; Sat, 2 Feb 2013 00:28:31 +0900 Received: from smtp-gw.biglobe.ne.jp ([172.21.56.79]) by vc-gw.biglobe.ne.jp (kbkr/0716090908) with ESMTP id r11FSV06017601 for ; Sat, 2 Feb 2013 00:28:31 +0900 X-Biglobe-Sender: Received: from [192.168.0.100] ([27.83.60.20]) by smtp-gw.biglobe.ne.jp id AABUAC15380F; Sat, 02 Feb 2013 00:28:31 +0900 (JST) Message-ID: <510BDF20.8010502@kbh.biglobe.ne.jp> Date: Sat, 02 Feb 2013 00:28:32 +0900 From: Yamaya Takashi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: toolchain@freebsd.org Subject: Re: [patch]r246028, libcxxrt's Version.map is broken References: <510AF84C.2080702@kbh.biglobe.ne.jp> In-Reply-To: <510AF84C.2080702@kbh.biglobe.ne.jp> Content-Type: multipart/mixed; boundary="------------070706020605060209040806" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 15:28:34 -0000 This is a multi-part message in MIME format. --------------070706020605060209040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Add missing symbol and refine. On 2013/02/01 08:03, Yamaya Takashi wrote: > Hi > > After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed. > libcxxrt's Version.map is broken, because some needed symbols are removed. > > > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" --------------070706020605060209040806 Content-Type: text/x-patch; name="vmap2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vmap2.patch" Index: lib/libcxxrt/Version.map =================================================================== --- lib/libcxxrt/Version.map (revision 246186) +++ lib/libcxxrt/Version.map (working copy) @@ -208,7 +208,6 @@ "typeinfo name for __cxxabiv1::__vmi_class_type_info"; "std::type_info::type_info(std::type_info const&)"; - "std::type_info::type_info(std::type_info const&)"; "std::type_info::operator=(std::type_info const&)"; @@ -238,19 +237,17 @@ "std::type_info::operator!=(std::type_info const&) const"; "std::bad_cast::bad_cast(std::bad_cast const&)"; "std::bad_cast::bad_cast()"; - "std::bad_cast::bad_cast(std::bad_cast const&)"; - "std::bad_cast::bad_cast()"; "std::bad_cast::operator=(std::bad_cast const&)"; + "std::bad_typeid::bad_typeid(std::bad_typeid const&)"; + "std::bad_typeid::bad_typeid()"; + "std::bad_typeid::operator=(std::bad_typeid const&)"; "std::exception::exception(std::exception const&)"; "std::exception::exception()"; - "std::exception::exception(std::exception const&)"; - "std::exception::exception()"; "std::exception::operator=(std::exception const&)"; + "std::bad_alloc::bad_alloc(std::bad_alloc const&)"; + "std::bad_alloc::bad_alloc()"; + "std::bad_alloc::operator=(std::bad_alloc const&)"; - - - - }; __cxa_allocate_dependent_exception; __cxa_current_primary_exception; @@ -281,15 +278,16 @@ "std::type_info::~type_info()"; "std::bad_cast::~bad_cast()"; + "std::bad_typeid::~bad_typeid()"; "std::exception::~exception()"; + "std::bad_alloc::~bad_alloc()"; + "std::exception::what() const"; + std::set_new_handler*; std::set_terminate*; std::set_unexpected*; - std::exception*; - std::bad_alloc; - std::bad_typeid; - std::type_info*; + std::type_info::__*; "vtable for std::bad_alloc"; "vtable for std::bad_cast"; @@ -299,10 +297,10 @@ "typeinfo for std::bad_alloc"; "typeinfo for std::bad_typeid"; - "typeinfo for std::exception"; "typeinfo for std::bad_cast"; "typeinfo for std::exception"; "typeinfo for std::type_info"; + "typeinfo name for std::bad_alloc"; "typeinfo name for std::bad_typeid"; "typeinfo name for std::bad_cast"; "typeinfo name for std::exception"; --------------070706020605060209040806--