> This looks like it’s trying to all a version with C++ name mangling. Try
> sticking an extern “C” { } around the #includes.
Thanks, David. That extern statement did not fix the compilation problem, but
I was able to simplify things by reverting to my original test program that
simply throws a C++ std::exception in code compiled with a .mm suffix. That
program now builds and runs correctly, whereas previously, it crashed. So I
think the changes we made do fix the problem.
Unfortunately, my main program is still crashing with a NULL exception. I'm
now wondering if there's something wrong with my build command, or maybe with
the runtime flags I'm passing to my main program.
I ran nm on the test program to see what exception personality it uses:
$ nm -C CXXException_mm|grep -i except
U __cxa_allocate_exception@@CXXABI_1.3
0000000000400ea4 r GCC_except_table0
U std::exception::~exception()@@GLIBCXX_3.4
00000000006020d0 V typeinfo for std::exception@@GLIBCXX_3.4
00000000006020a0 V vtable for std::exception@@GLIBCXX_3.4
I checked for those strings in my main program, and the result was similar,
although not identical:
$ nm -C obj/mapmaker|grep __cxa_allocate_exception
U __cxa_allocate_exception@@CXXABI_1.3
(ALSI8)dlobron@bos-lps80:~/build/clangport/akamai/mapmaker$ nm -C
obj/mapmaker|grep std::exception
U std::exception::~exception()@@GLIBCXX_3.4
U typeinfo for std::exception@@GLIBCXX_3.4
The only difference here is that the non-working main program doesn't have
"vtable for std::exception". Could that be the source of the problem? Or
could this be a runtime or compile-time difference in my code?
--David
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
