[LLVMdev] conflicting c++ libs for building dragonegg
Jack Howarth
howarth at bromo.med.uc.edu
Fri Aug 30 06:56:05 PDT 2013
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.
More information about the llvm-dev
mailing list