libcxx, libcxxabi, and runtime_error

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:

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

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

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

I found the root cause. The pertinent clue was in the stackoverflow article: "gcc will, on sufficient optimization levels, actually alias the symbols to the same code". It turns out that clang/llvm does this aliasing. For our architecture, there is (soon to be 'was') a bug in some code in AsmPrinter::doFinalization specifically added to support our assembler semantics which was causing the final alias to not appear in our .s file (we do not yet directly generate object files)

Regards,

  Richard Gorton

I found the root cause. The pertinent clue was in the stackoverflow article: "gcc will, on sufficient optimization levels, actually alias the symbols to the same code". It turns out that clang/llvm does this aliasing. For our architecture, there is (soon to be 'was') a bug in some code in AsmPrinter::doFinalization specifically added to support our assembler semantics which was causing the final alias to not appear in our .s file (we do not yet directly generate object files)

Glad to hear that you found the problem.

— Marshall