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: > > > > > On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: > > > > > > 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... > > > 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. > > > > Added > > > > > 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. > > > > 0x0000000000000001 (NEEDED) Shared library: [libcxxrt.so.1] > > > > This is with something compiled with -stdlib=libc++. 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. > > > > 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.
pgpKQhR7iEfFy.pgp
Description: PGP signature
