C++ runtime version patch for testing

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130128/3cc18ca4/attachment.sig>