[cfe-dev] clang, g++, icc link compatibity?
James Y Knight
jyknight at google.com
Mon May 11 15:16:29 PDT 2015
You can enable the old ABI with libstdc++ 5.X, via building your software
with -D_GLIBCXX_USE_CXX11_ABI=0. That'll work fine if you only depend only
on libstdc++ itself, because libstdc++ exports symbols for both the old and
new ABIs at the same time.
But if your program depends on other C++ libraries that themslves expose
c++ std types in their API, and which have been built against the new ABI,
then you're in trouble, because clang cannot compile correctly for the new
ABI. So, clang on Fedora 23 should be broken, as they've apparently
rebuilt all libraries for the new ABI, and I'm sure nobody but libstdc++
bothers to export symbols for both the old and new ABIs.
See
http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/
for some more info.
On Mon, May 11, 2015 at 5:18 PM, Richard Smith <richard at metafoo.co.uk>
wrote:
> On Mon, May 11, 2015 at 12:47 PM, C Bergström <cbergstrom at pathscale.com>
> wrote:
>
>> On Tue, May 12, 2015 at 2:21 AM, Christian Convey
>> <christian.convey at gmail.com> wrote:
>> > So, modulo any shenanigans about clang and gcc finding different STL
>> > headers/libs, and modulo any bugs, as long as they're using the same
>> Itanium
>> > ABI version, I'm probably okay?
>>
>> In theory yes, but in practice I would not count on this at all.
>>
>> Think about it another way - if you have an object compiled with
>> g++-4.1 would you try to link and include it with other objects built
>> with clang or gcc-5?
>>
>
> Compatibility with GCC 5 is worth mentioning on its own merits:
>
> libstdc++ from version 5 onwards uses a new abi_tag mechanism, which Clang
> does not yet support. Do not expect libstdc++ v5 onwards to work with Clang
> for the time being (unless you turn that mechanism off somehow).
>
> This is regrettable: abi_tag is only marginally better than the standard
> solution of inline namespaces (you can tag member functions, not just
> namespace-scope entities, but otherwise it's essentially the same at the
> ABI level), and it means that GCC / libstdc++ is now sort-of deliberately
> violating the cross-vendor ABI. But... the GNU project is unlikely to be
> interested in making their code work with non-GCC compilers, so this is our
> problem to solve.
>
> FreeBSD, Linux and Solaris all use the Itanium ABI - Would you try to
>> take an object compiled on Solaris and link it against some stuff for
>> Linux. (This is an absurd example, but I hope it really shows my
>> point)
>>
>> Bugs are unavoidable and c++ is *hard*
>>
>> Don't get me wrong - I'm trying to give a conservative answer.
>> ------------
>> (Disclaimer - I'm biased because I work on compilers for a living and
>> tell people to always recompile their c++ codes.)
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150511/38ff514e/attachment.html>
More information about the cfe-dev
mailing list