[cfe-dev] libc++abi on linux

[Chris Lattner]

On Jul 8, 2012, at 8:00 PM, 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
> 
> It would be nice to have a documented/tested/working way of compiling 
> *and linking* programs using libc++/clang/llvm on linux, it seems that 
> libc++abi is pretty close to getting that working.
> 
> This comes up on the list every couple of months and libcxxrt/libunwind 
> are usually suggested over libc++abi.

Actually, the only people that suggest that are the pathscale folks.

> What is the problem?  Is there some disagreement about the scope of 
> libc++abi?  Is there some specific part that has been excluded that is 
> required on linux but not darwin?  Does libc++abi replace libsupcxx (not 
> entirely)?  Does libunwind address just the missing bit or is there 
> overlap? If there is overlap is linking order enough to fix that? is 
> libc++abi equivalent to libcxxrt? And there are lots of other questions 
> that come up and it just makes it hard to get going.

The intention is that libc++abi + libc++ is a replacement libstdc++ in its entirety.  It is factored the way it is because Apple ships the "STL part" of libstdc++ on top of libc++abi: the ABI library is the common linkage between the two STL implementations.  It is a pretty direct replacement for libsupc++, but may not be a 100% analogue (I don't recall).

> I think it's a real shame that this is not documented for linux, I 
> suspect it is preventing the uptake of libc++ with clang on linux and 

I completely agree.  I really don't care for the distracting pushes towards the pathscale libraries.

-Chris