llvm dev - Aug 2013 - [LLVMdev] conflicting c++ libs for building dragonegg

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.

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.

On 30 Aug 2013, at 19:42, Duncan Sands <baldrick at free.fr> wrote:
> First off, is libc++ supposed to be incompatible with
> libstdc++?
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