[LLVMdev] conflicting c++ libs for building dragonegg

[Jack Howarth]

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.
        Jack

>
> Ciao, Duncan.