Date: Mon, 28 Jan 2013 09:26:49 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Re: C++ runtime version patch for testing Message-ID: <20130128072649.GR2522@kib.kiev.ua> In-Reply-To: <20130127161551.GO2522@kib.kiev.ua> References: <EDDAA896-D752-450F-89A0-4831FB016AC5@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <some binary> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130128072649.GR2522>