[cfe-dev] libc++abi on linux
Richard Smith
richard at metafoo.co.uk
Mon Jul 9 23:31:47 PDT 2012
On Mon, Jul 9, 2012 at 6:40 PM, Ashok Nalkund <ashoknn at qualcomm.com> wrote:
> On 7/9/2012 6:08 PM, Marshall Clow wrote:
>
>> On Jul 9, 2012, at 5:46 PM, Nick Kledzik wrote:
>>
>>> On Jul 9, 2012, at 2:34 PM, Ashok Nalkund wrote:
>>>
>>>> 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:
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> That is what I don't understand about this thread. Is the problem that
>>> libgcc_s.so (which implements _Unwind_* functions) does not exits on these
>>> systems? Or is the problem that the unwind header is missing?
>>>
>>
>> Either, or both. Or people don't want to use libgcc; which is, after all,
>> GPL.
>> AFAICT, Apple keeps libgcc_s around for old binaries built with gcc;
>> binaries built with clang + libc++ don't use it.
>>
>
> I didnt know that libgcc_s.so implements the unwind.h, its more clear to
> me now, thanks. For me, the concern is that libgcc_s.so is GPL. So now the
> question is, is there a recommended replacement for libgcc_s.so?
>
I've built a toolchain using libunwind, libc++abi, libc++, and Clang, with
no libstdc++ and no libgcc_s. It's rough around the edges, but it can be
made to work. I've not tried replacing libgcc with compiler-rt, and it's
still depending on gcc for crt*.o, but other than those pieces, it doesn't
depend on a gcc installation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120709/bca9a5f7/attachment.html>
More information about the cfe-dev
mailing list