conflicting c++ libs for building dragonegg

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

conflicting c++ libs for building dragonegg

Jack Howarth-3
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: conflicting c++ libs for building dragonegg

Duncan Sands
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: conflicting c++ libs for building dragonegg

Jack Howarth-3
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: conflicting c++ libs for building dragonegg

Duncan Sands
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: conflicting c++ libs for building dragonegg

David Chisnall-5
On 30 Aug 2013, at 19:42, Duncan Sands <[hidden email]> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: conflicting c++ libs for building dragonegg

Howard Hinnant-2
On Aug 30, 2013, at 3:42 PM, David Chisnall <[hidden email]> wrote:

> On 30 Aug 2013, at 19:42, Duncan Sands <[hidden email]> 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.  

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev