discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Link error building a .m tool with clang on Linux


From: Lobron, David
Subject: Re: Link error building a .m tool with clang on Linux
Date: Fri, 5 Jan 2018 16:05:16 +0000

Thanks, Ivan, David and Wolfgang.  

>> ../AkamaiKit.framework/Versions/Current/./libAkamaiKit.so: undefined 
>> reference to `vtable for gnustep::libobjc::__objc_class_type_info'
> 
> This will happen if you’ve used Objective-C++ and are on a platform that 
> ships its stack C++ in a stupid way.  By default on these platforms, 
> libobjc.so avoided linking to the C++ standard library and instead provided a 
> libobjcxx.so.
> 
> This has confused everyone, so trunk and the upcoming 1.9 release will always 
> link to libstdc++.so / libc++.so if this is the only way of getting access to 
> the symbols provided by libsupc++ / libcxxrt.
> 
> For now, adding -lobjcxx on platforms where libobjcxx.so exists will fix the 
> issue (unless you built libobjc without Objective-C++ support, in which case 
> you have a different problem).

I'm definitely attempting to build libobjc2 with Objective-C++ support.  But, 
checking my CMake configure output for libobjc2, it looks like I'm on one of 
those dysfunctional platforms (Ubuntu Linux in my case):

-- Testing C++ interop
-- Testing C++ standard library
-- No useable C++ runtime found

This sets ENABLE_OBJCXX to false, so the following code in CMakeLists.txt is 
not executed:

if (ENABLE_OBJCXX)
        if (NOT CXXRT_IS_STDLIB)
                # We don't want to link the STL implementation (e.g. libstdc++) 
if
                # we have a separate C++ runtime.
                set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "")
                target_link_libraries(objc ${CXX_RUNTIME})
        endif()
        set(libobjc_CXX_SRCS ${libobjcxx_CXX_SRCS})
        target_sources(objc PRIVATE ${libobjcxx_CXX_SRCS})
endif()

Possibly because of the above, my build is not producing libobjcxx.so:

$ find . -name libobjcxx.so
$

David, from what you said above, it sounds like we *do* want to build 
libobjcxx.so if there's no usable C++ runtime and ENABLE_OBJCXX is true.  
Should we re-work this code so that we build libobjcxx.so if ENABLE_OBJCXX is 
true and no usable C++ runtime is found?  Of course, we'd then also want to add 
-lobjcxx to our link command, or possibly use clang++ for linking, as Wolfgang 
suggested (to answer Ivan's question: I'm using the latest gnustep-base, 
gnustep-make, and libobjc2 codelines from github, synced a day or two ago).

--David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]