[LLVMdev] conflicting c++ libs for building dragonegg

Duncan Sands baldrick at free.fr
Fri Aug 30 11:42:32 PDT 2013


Hi Jack,

On 30/08/13 15:56, Jack Howarth wrote:
> On Thu, Aug 29, 2013 at 07:40:46PM +0200, Duncan Sands wrote:
>> Hi Jack,
>>
>> On 29/08/13 18:35, Jack Howarth wrote:
>>> 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 (https://wiki.freebsd.org/NewC%2B%2BStack).
> 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.



More information about the llvm-dev mailing list