[cfe-dev] clang, g++, icc link compatibity?

[Richard Smith]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150511/19ffe224/attachment.html>