On 16 Nov 2017, at 21:41, Lobron, David <[email protected]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
