[cfe-dev] libc++abi on linux

[Ashok Nalkund]

On 7/9/2012 2:11 PM, Richard Smith wrote:
> On Mon, Jul 9, 2012 at 9:44 AM, Ashok Nalkund <ashoknn at qualcomm.com
> <mailto:ashoknn at qualcomm.com>> wrote:
>
>     On 7/9/2012 9:16 AM, Chris Lattner wrote:
>      >
>      > 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).
>      >
>     So could you suggest a replacement for unwind? libc++abi + libc++ still
>     requires unwind.h, and my temporary solution is to pull it from gcc.
>
>
> You could pull it from libunwind instead. Ultimately, it seems to me
> that we should fix Clang's unwind.h to provide all the necessary
> declarations. Is there any reason not to do so? The current
> #include_next approach suggests that there might be some Darwin-specific
> concerns there?

But is that all, just the unwind.h? The libunwind projects (PathScale or 
nongnu website) provide more files and require compilation etc.