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.
David Chisnall
2013-Aug-30 19:42 UTC
[LLVMdev] conflicting c++ libs for building dragonegg
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
Reasonably Related Threads
- [LLVMdev] conflicting c++ libs for building dragonegg
- [LLVMdev] conflicting c++ libs for building dragonegg
- [LLVMdev] conflicting c++ libs for building dragonegg
- [LLVMdev] conflicting c++ libs for building dragonegg
- clang++ build from source is not able to find C++ headers