[cfe-dev] libc++abi on linux

[Richard Smith]

On Mon, Jul 9, 2012 at 9:44 AM, Ashok Nalkund <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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120709/5b63a519/attachment.html>