Date: Sun, 27 Jan 2013 18:15:51 +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: <20130127161551.GO2522@kib.kiev.ua> In-Reply-To: <864783A2-E48D-49A6-AD3E-6EABE6EB5313@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <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. > > 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130127161551.GO2522>