Re: Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2

[David Chisnall]

On 16 Nov 2017, at 21:41, Lobron, David <dlobron@akamai.com> wrote:
> 
> I did a verbose build of libobjc2.  The compilation line for CXXException.cc 
> looks like this:
> 
> [ 48%] Building CXX object Test/CMakeFiles/CXXExceptions.dir/CXXException.cc.o
> cd /home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/build/Test && 
> /usr/bin/clang  -DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH 
> -D_BSD_SOURCE=1 -D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 
> -D__OBJC_RUNTIME_INTERNAL__=1 
> -I/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1  
> -fobjc-runtime=gnustep-1.7 -fblocks -O0 -o 
> CMakeFiles/CXXExceptions.dir/CXXException.cc.o -c 
> /home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/Test/CXXException.cc
> 
> I noticed that -fobjc-runtime is set to gnustep-1.7 rather than gnustep-1.8.  
> Could that be the problem?

No, that’s fine - there are no compiler changes between 1.7 and 1.8, it’s just 
good practice to keep the flag and the runtime version in sync.

> This line also seemed suspicious:
> 
> /home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang 
> -std=gnu99  -fexceptions  -rdynamic 
> CMakeFiles/CXXExceptions.dir/CXXException.m.o 
> CMakeFiles/CXXExceptions.dir/CXXException.cc.o  -o CXXExceptions 
> -Wl,-rpath,/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/build 
> ../libobjc.so.4.6
> 
> Could the gnu99 or -fexceptions be the problem? 

Nope, gnu99 is a perfectly acceptable C dialect (the tests don’t use any C11 
features yet) and you definitely want -fexceptions to make sure that exceptions 
are enabled!

> 
> I've copied all the lines leading up to the error below.  CXXException.cc 
> seems to be the source of the error, which seems very suggestive.

It seems to be missing the linker command line for building the CXXException 
test.  It’s probably worth taking a step back at this point:

On Linux platforms, it’s common to provide libsupc++ (the GNU C++ runtime 
library) statically linked into libstdc++ (the GNU C++ standard library).  This 
is somewhat awkward, because this means that the only way to use symbols in 
libsupc++ is to add a dependency on libstdc++.  I’ve tried to avoid that for 
libobjc, because libstdc++ is a big library and is completely unused for pure 
Objective-C programs.

On FreeBSD, we ship libcxxrt (the BSD C++ runtime, which I wrote) as a separate 
.so and link both libstdc++ and libc++ (the LLVM C++ standard library) to it 
dynamically, so we can support programs linked to both.  This means that on 
FreeBSD we ship libobjc.so dynamically linked to libcxxrt.so, and that doesn’t 
add much to the dependency footprint for any Objective-C project.

By default, the libobjc CMake build looks for libcxxrt.so or libsupc++.so and, 
if it doesn’t find them, will build a libobjcxx.so that links to libstdc++ and 
to libobjc.so.  This extra library provides the required functionality for 
Objective-C++.  If you are seeing this being built, then you will need to link 
it for Objective-C++ to work.  This configuration isn’t as well tested, because 
I don’t use any platforms that package things like this on a regular basis.

TL;DR: Can you try adding -lobjcxx and see if that makes things work again for 
you?

David