[cfe-dev] libc++abi on linux

["C. Bergström"]

On 07/ 9/12 10:00 AM, Ben Pope wrote:
> On Monday, July 09, 2012 08:49 AM, "C. Bergström" wrote:
>> libcxxrt + libunwind is the way to go imho
>> https://github.com/pathscale/libcxxrt
>> https://github.com/pathscale/libunwind
>>
>> These have been tested to work with clang - Admittedly the build process
>> may not be straight forward, but if enough interest maybe we solve that
<snip>
> clang++ -std=c++11 -stdlib=libc++ -stdlibabi=libc++abi -stdlibunwind?=???
>
> Really that line starts to get a bit scary
That scary line is not a problem limited to clang, but really any 
compiler which has multiple STL/runtimes that it may work with.  The 
"problem" is that these really should be build time options that define 
a default for the compiler and avoiding having to manually specify them 
at all.  (IMHO and others may disagree)

>   that the missing bits (abi/unwind) can
> be made to Just Work(tm).
For our project outside of clang/llvm we made a top level wrapper build 
system that forces everything to be built at once.  I would say this is 
more of a packager and potentially end user convenience than a 
developer/development requirement.  (Since building standalone 
components is usually easier/faster than a whole suite of things bundled 
together)

I don't know when "we" (PathScale) will have time, but I think we should 
modify our wrapper[1] to be more llvm/clang friendly and solve this damn 
problem once and for all.

(Keep in mind that the approach I'm talking about may have "downsides" - 
such as making the default system C++ compiler and the clang++ not 
compatible -  afaik this would mostly be limited to libc++ issues, but I 
digress)

./C

[1] https://github.com/pathscale/path64-suite - I think you could just 
kick out our compiler and put clang/llvm in there as a sub project w/o 
too much issue