[cfe-dev] libcxx, libcxxabi, and runtime_error

[Richard Gorton]

Do I need to configure llvm/clang 3.3 with --enable-cxx11 to build libcxx/libcxxabi?


On May 27, 2014, at 3:44 PM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:

> Thank you for the quick response.  As an experiment, I did an svn export of both libcxx/libcxxabi from the current llvm project, and applied my porting changes to my local copy.
> Unfortunately I still hit the same problem.  I did observe that I did have a: "#define LIBCXXRT 1" in my libcxx/include/__config for my architecture, which I think is incorrect (but I'm not clear about what impact it has).
> 
> I'll keep investigating, and report back with whatever I find.
> 
> Have others been able to do a libcxx/libcxxabi port to an architecture which does not already have a backing gcc+libs?
> 
> Regards,
> 
> 	Richard Gorton
> 
> 
> On May 27, 2014, at 10:42 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
>> 
>> On May 27, 2014, at 6:09 AM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:
>> 
>>>> Hi - I'm trying to get C++ support for our architecture up and working (as a cross compiled environment) and I'm encountering some link errors:
>>>> 
>>>> build/lib/libc++.a(locale.cpp.o):(.data.rel.ro+0x2d0): undefined reference to `std::runtime_error::~runtime_error()'
>>>> 
>>>> 
>>>> When I nm libcxx:locale.cpp.o, I see:
>>>>              U _ZNSt13runtime_errorD1Ev
>>>> 
>>>> 
>>>> In libcxxabi:stdexcept.o, I see:
>>>> 0000000000000150 T _ZNSt13runtime_errorD0Ev
>>>>              U _ZNSt13runtime_errorD1Ev
>>>> 00000000000001f8 T _ZNSt13runtime_errorD2Ev
>>>> 
>>>> That is, in both cases, …runtime_errorD1Ev is undefined.
>>>> 
>>>> When I use c++filt to demangle the symbols listed in stdexcept.o, they all decode to
>>>> 	std::runtime_error::~runtime_error()
>>>> 
>>>> 
>>>> Any suggestions as to how to determine what is happening and why?
>>>> 
>>>> My setup: clang/llvm 3.3, with libcxx from the 3.3 release; libcxxabi is much more recent (6-May-2014, svn rev 208087)
>> 
>> I’m guessing that that’s your problem.
>> ISTR that there was some migration of destructors between libc++ and libc++abi in the 3.3/3.4 time frame.
>> (Though I would have expected multiple definitions, rather than no one defining it).
>> 
>> If you’re using libc++abi, then it should define the destructors for standard library exception classes.
>> 
>> — Marshall
>> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev