llvm dev - Aug 2013 - [LLVMdev] 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,

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.

Ciao, Duncan.

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.