search for: 2bstack

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

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

...ught 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++ su...