Bug#797917: Actually this bug makes clang not so useful

[Gianfranco Costamagna]

Hi Danny,

>$ g++ -std=c++98 -o options options.cpp -lboost_program_options
>$ clang++ -std=c++98 -o options options.cpp -lboost_program_options



the fact  is that even if your code is not directly using c++11 symbols,
the underlying libraries (boost_program_options in this case) are, so you
can't mix both old and new ABI.

objdump -T /usr/lib/x86_64-linux-gnu/libboost_program_options.so |grep cxx
echo 
"_ZN5boost9from_utf8ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE" 
|c++filt 
boost::from_utf8(std::__cxx11::basic_string const&)


so yes, you can't use boost, until clang gets ported to a new c++11 ABI.

cheers,

G.

Bug#797917: Actually this bug makes clang not so useful

[Danny Edel]

On 04/09/15 11:23, Gianfranco Costamagna wrote:
> 
> I guess clang is not useful for cxx11 projects until llvm folks finds
> a way to make it use the new ABI.
> 

Hi everyone,

I just want to make clear that this is *not* specific to c++11 projects.
Even if you don't use any c++11 features, clang can't link against the
library.

Try compiling my example code (which is valid c++98) with

$ g++ -std=c++98 -o options options.cpp -lboost_program_options
$ clang++ -std=c++98 -o options options.cpp -lboost_program_options

The results are the same - works on gcc, fails to link on clang on sid,
while both commands used to work on stable.

If I understand the consequences of this failure right, this will
severely impact the usefulness of clang++, since it will start failing
to link against *any* c++ library compiled by recent g++, breaking
unchanged and valid user code - be it c++11, c++03 or c++98.

I don't think this is that much of an issue on sid - after all, it's
called "unstable" for a reason - but it might be a showstopper for
stable, if clang++ is to be an alternative for g++.

- Danny

Bug#797917: Actually this bug makes clang not so useful

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Danny,

> If we could make those "Dual-ABI compile flags" the default on 
> gcc-compiled libraries, clang upstream should have enough time 
> implementing [abi:cxx11] and remain usable in Debian.


gcc had the dual ABI enabled.

but it got disable in the experimental/unstable uploads:
https://packages.qa.debian.org/g/gcc-5/news/20150616T170514Z.html

I guess clang is not useful for cxx11 projects until llvm folks finds
a way to make it use the new ABI.

sorry, but I don't see how to fix this, for sure enabling again the
dual ABI in gcc (not even sure if it will work), is a no-go, because
I'm pretty sure it will trigger another painful transition.

I'm sorry but we should live with this, until llvm folks implemtents
the new code.

Sylvestre, doko, what is your opinion?

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6WL+AAoJEPNPCXROn13ZLSwP/jKdByzGcE69N6tMFqRcnrfE
cX4HsZl/ctH+s2++Gf/ViHTOJT96Zearw8IQ3+Z8582YMjw+240fxaRsGJfX4CFr
7zjA9sd3Otk+hailJm67qh6zW58Jw5v/izG5mGQUf6wA4ZSVZ9yqNVOE/9fKuI1x
2lyAt3KELt6wIjgZgjLkwCqndiP8JTpERqNHn+1D2G3FjDAfppWQfiScUu6WfBsC
WPGFl6BzfUWKoXBjBfhcpDEO4HbQ7RUz5AoNK55YVjemU1oy+gqWwXC2alUA6jVt
QOEeq00/iDVptH1E2UCYraUp6bd8ebKlxmWOhmQfW1ubQRTrYFlFM9Fs5SBLnqoT
GnsUHaW/GbPTY+eRtbI3WUiAwsDCdhDAVL3ROXmGN/quPZwYp7YsdB3U70sOd3H+
Kj/PXT/w8FpVeK4ak1LrQB6xCxeG49KPHFJ1KYD04OCsVHugtTdzy1WzRbbHvofV
MPdbbAFGAbI9MGux81+w0HSfZKbkK2DyXjYG4IfYMUpczlyL/4gN4VVJabVB3LNP
6tApQjJf3OivtJBESMUuWwf3TXziUce/GpUvulCVGcEsHJWYiJy7aU22/rl0ZGDw
CceAM6gjNI14XU+ejTF6Xcs2obVK3VPbleHeDG5jNN86F9P4Osy3clYZLMAJwRks
ai/12PvO7FQpYeAb89or
=L2mz
-END PGP SIGNATURE-

Bug#797917: Actually this bug makes clang not so useful

[Danny Edel]

On Thu, 3 Sep 2015 17:45:27 + (UTC) Gianfranco Costamagna
 wrote:
> according to [1] there might be no fix.
> 

This may not be a permanent fix, but Debian could take up the "dual-abi"
idea that gcc upstream does with their libstdc++.so.6.

Example:

$ nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt | grep
std::locale::name
0009e300 T std::locale::name[abi:cxx11]() const
000b8900 T std::locale::name() const

For reference, the un-beautified symbol names are

0009e300 T _ZNKSt6locale4nameB5cxx11Ev
000b8900 T _ZNKSt6locale4nameEv


The symbol is exported twice, once with the new ABI and once with the
old. If someone™ figured out how to make the gcc compiler do that, boost
(and other libraries') maintainers could adapt those flags when
compiling with gcc, so we don't generate a vendor lock-in.

If we could make those "Dual-ABI compile flags" the default on
gcc-compiled libraries, clang upstream should have enough time
implementing [abi:cxx11] and remain usable in Debian.

- Danny