C++ runtime version patch for testing

[Konstantin Belousov]

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.
-------------- 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/20130127/b4cfc287/attachment.sig>