conflicting c++ libs for building dragonegg

Duncan,
   Is there a long term plan for handling the conflicting c++ libraries in building
dragonegg? In particular, as vendors switch their clang++ system compilers to default
to -stdlib=libc++, the resulting builds of llvm against those compilers will be using
the libc++ ABI but the dragonegg plugin will still need to be built against the
libstdc++ ABI. For now, the only work-around appears to be building llvm with
-stdlib=libstc++.
       Jack

Hi Jack,

Hi Jack,

Duncan,
    Is there a long term plan for handling the conflicting c++ libraries in building
dragonegg? In particular, as vendors switch their clang++ system compilers to default
to -stdlib=libc++, the resulting builds of llvm against those compilers will be using
the libc++ ABI but the dragonegg plugin will still need to be built against the
libstdc++ ABI. For now, the only work-around appears to be building llvm with
-stdlib=libstc++.

I didn't understand the problem.

Duncan,
   It seems rather obvious. Both FSF gcc and dragonegg are built as c++ code so they use
the libstdc++ c++ library but as distributions switch clang++ to default to the libc++
c++ shared library, the llvm code loaded by the dragonegg plugin will be built with
a different and incompatible c++ library. My question is whether any thought has been
given to addressing potential issues (such as throwing exceptions across code built with
different c++ libraries). FreeBSD may be able to solve such issues with their libcxxrt
shim library but darwin isn't going to have such a beast (NewC++Stack - FreeBSD Wiki).
Currently the only safe approach on darwin would seem to be building dragonegg against a copy
of llvm built with -stdlib=libstc++ to avoid mixing the two different c++ libraries in
the gcc -> dragonegg -> llvm code execution path.
        Jack

Hi Jack,

Hi Jack,

Duncan,
     Is there a long term plan for handling the conflicting c++ libraries in building
dragonegg? In particular, as vendors switch their clang++ system compilers to default
to -stdlib=libc++, the resulting builds of llvm against those compilers will be using
the libc++ ABI but the dragonegg plugin will still need to be built against the
libstdc++ ABI. For now, the only work-around appears to be building llvm with
-stdlib=libstc++.

I didn't understand the problem.

Duncan,
    It seems rather obvious. Both FSF gcc and dragonegg are built as c++ code so they use
the libstdc++ c++ library but as distributions switch clang++ to default to the libc++
c++ shared library, the llvm code loaded by the dragonegg plugin will be built with
a different and incompatible c++ library. My question is whether any thought has been
given to addressing potential issues (such as throwing exceptions across code built with
different c++ libraries). FreeBSD may be able to solve such issues with their libcxxrt
shim library but darwin isn't going to have such a beast (NewC++Stack - FreeBSD Wiki).
Currently the only safe approach on darwin would seem to be building dragonegg against a copy
of llvm built with -stdlib=libstc++ to avoid mixing the two different c++ libraries in
the gcc -> dragonegg -> llvm code execution path.

sorry to be obtuse. First off, is libc++ supposed to be incompatible with
libstdc++? If it isn't supposed to be, but is in practice, then that's a bug
in those libs that should be fixed. So let's suppose they are supposed to be
incompatible. Then you have an example of the following situation: two
compilers, compiler A and compiler B, such that code built with compiler A
(clang++) is incompatible with code built with compiler B (g++), at least with
their default settings. If you have two such incompatible compilers, and you
need to link some of your own code with a library compiled with compiler A,
then clearly you need to compile your own code with compiler A too. Applying
this to the specific case of dragonegg, as dragonegg needs to link with a
library (LLVM) that has been built with compiler A, it seems to me that the
conclusion is that dragonegg itself should be built with compiler A. In short,
why don't you just build dragonegg with clang++?

Ciao, Duncan.

libc++ does not, and never had, ABI compatibility with libstdc++ as a goal. Actually, libstdc++ periodically breaks ABI compatibility too, as we have recently found in the FreeBSD ports tree with certain projects requiring a newer libstdc++ than the one we ship in the base system. On OS X and FreeBSD 10, libc++ are the default STL implementations and so LLVM / clang / anything that doesn't explicitly request something else will be compiled with libc++. If DragonEgg doesn't compile with libc++, then it can not invoke any LLVM methods that take as arguments or return STL types without causing ABI-incompatibility problems.

David

Fwiw, the libc++ std-defined exception types are ABI compatible with those of libstdc++. However that is not a completely working feature out of the box. To really be able to throw/catch across these two libs one would need to ensure that:

1. They are both using the same implementation of the Itanium ABI (what llvm calls libc++abi).

2. That the type_infos of the two will compare equal. If comparing by identity, then the type_infos will need to be uniqued. The current design is that the type_infos are laid down by libc++abi.

Howard