Been dealing in linker hell for the past day and figured I'd throw this out there and see if anyone could help me out.
I have two shared libraries that I'm building: one called "libhttp" that has some helper functions for the http protocol which seems to be building for better or worse OK. The second is called "libvpcutil" which is causing the issues. It depends on symbols that are in libhttp so I link it against libhttp. Here's the compilation directive (exploded from the make file) with minor things like my personal path to openssl generified:
g++ -shared -Wl,-soname,libvpcutil.so.1 -o libvpcutil.so.1.0 vpcreg/registry.o \
vpcreg/vpcreg2.o dbase/dbase.o dbase/sqlutils.o diaglog/diaglog.o errmsg/errmsg.o \
faillib/faillib.o failover/failover.o initerr/init_err.o kmq/kmq.o kmq/publish.o \
kthread/kcom.o kthread/kthread.o libobdi/odi_serv.o mutex/mutex.o netserv/netserv.o \
newmem/newmem.o rmtstore/avlmem.o rmtstore/rmtstore.o rmtstore/shm_aloc.o \
servhand/servhand.o timers/timers.o vpcstamp/vpcstamp.o websql/websql.o types/blob.o \
types/hitime.o types/ticks.o types/timestamp.o odasm/odasm.o webvibapi/webvibapi.o \
vibusfeed/vibusfeed.o propstore/propstore2.o cardlib/cardlib.o cardlib/sortlist.o \
gapi/genapi.o -L/usr/lib/i386-linux-gnu -lm -lrt -lxml2 -lodbc -L/usr/lib/i386-linux-gnu -\
lcurl -Wl,-Bsymbolic-functions -Wl,-z,relro \
-L/pathtoopenssl/openssl -lssl -lcrypto -lxml2 -lreadline -\
lcurses -Wl,-rpath=.:/pathtobin/bin http/libhttp.so.1.0 ../ddldata/ddldata.o
../cardddl/cardddl.o ../gendata/generic.o
The compilation and linking completes successfully. Hopefully you noted the link step to http/libhttp.so.1.0.
Now, if I do a nm on libhttp.so.1.0, I get the following output (amongst others):
00015d5a T _ZN12http_cookiesC1Ev
00015d5a T _ZN12http_cookiesC2Ev
00015d7e T _ZN12http_cookiesD1Ev
00015d7e T _ZN12http_cookiesD2Ev
00011574 T _ZN12http_headers11url_expressERSo
00011466 T _ZN12http_headers12http_expressERSo
But when I do a nm on libvpcutil.so.1.0 I get essentially:
U _ZN12http_cookiesC1Ev
U _ZN12http_cookiesD1Ev
U _ZN12http_headers11url_expressERSo
U _ZN12http_headers3setEPKcRKSs
U _ZN12http_headers3setEPKcS1_
U _ZN12http_headersC1Ev
U _ZN12http_headersD1Ev
I'm obviously snipping here, but where I'm stuck here is the symbols are clearly defined in libhttp, I link against it for libvpcutil, but then the symbols are undefined in libvpcutil. This creates runtime errors.
Anyone see the issue?
That looks like the expected behaviour.
Linking to a shared library is not like linking to a static library, the required symbols do not get copied into the output file, you just get a reference to the symbol which must still be resolved at run-time. So it's normal that the symbols are shown as U by nm.
What are the run-time errors? It probably means the libhttp.so.1.0 library isn't found at run-time. You should be able to run ldd on libvpcutil.so and on the executable to see if they depend on libhttp.so.1.0 and if they're finding the right one.
Does libhttp.so.1.0 have a soname set? If it's not the same as the filename, do you have a symlink with the same name as the soname? (e.g. if the soname is libhttp.so.1 you'll need a symlink libhttp.so.1 -> libhttp.so.1.0). I also see your libhttp.so.1.0 is in a directory called http but that's not in your RPATH, so won't be found at runtime.
Related
I am very much lost here and could really use some help.
I'm working on an Honours project for next year that involves a physics simulation using Bullet and Vulkan for rendering. After a few months of work I have most of the project functioning. It needs a lot of refactoring and cleaning which will be the next stage.
I have been using a makefile but wish to migrate to CMake for a few reasons. Mainly because it seems to be the standard and because I want to compile for different OS's in the future (I'm running Linux but may need to deploy on Windows or Mac). Finally, I was recompiling the whole project for even a small change, which was beginning to become a problem as I started Unit Testing more.
The old makefile is as follows :
ROOT_DIR:=$(shell dirname $(realpath $(firstword $(MAKEFILE_LIST))))
OWN_INCLUDES = \
-I$(ROOT_DIR)/src/Domain \
-I$(ROOT_DIR)/src/Vk \
-I$(ROOT_DIR)/src/Ui \
-I$(ROOT_DIR)/src/Service
ADD_INCLUDES = \
-I/opt/bullet3-master/src \
-I/opt/vk_mem_alloc \
-I/opt/stb_image \
-I/opt/tiny_obj_loader/ \
-I/opt/imgui-vulkan/
BULLET_INCLUDE_PATHS_LIBS = -L/opt/bullet3-master/src/BulletCollision/ \
-L/opt/bullet3-master/src/BulletDynamics/ \
-L/opt/bullet3-master/src/LinearMath/ \
-lBulletDynamics -lBulletCollision -lLinearMath
VULKAN_SDK_PATH = /opt/Vulkan_SDK/1.2.162.1/x86_64
CFLAGS = -std=c++17 -I$(VULKAN_SDK_PATH)/include $(OWN_INCLUDES) $(ADD_INCLUDES)
LDFLAGS = -L$(VULKAN_SDK_PATH)/lib `pkg-config --static --libs glfw3` -lvulkan $(BULLET_INCLUDE_PATHS_LIBS)
IMGUI_CPP_PATHS = /opt/imgui-vulkan/*.cpp
OWN_CPP_PATHS = src/*.cpp src/Domain/*.cpp src/Vk/*.cpp src/Ui/*.cpp src/Service/*.cpp
###### Unit Testing Paths
UNIT_TEST_INCLUDE = -I/opt/catch-header/
UNIT_TESTS_PATH = $(ROOT_DIR)/unit_tests/*.cpp
VulkanRun: $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS)
g++ $(CFLAGS) -o VulkanRun $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS) $(LDFLAGS)
Unit_Test: $(UNIT_TESTS_PATH) src/Domain/*.cpp src/Vk/*.cpp src/Ui/*.cpp src/Service/*.cpp $(IMGUI_CPP_PATHS)
g++ $(UNIT_TEST_INCLUDE) $(CFLAGS) -o Unit_Test $(UNIT_TESTS_PATH) src/Domain/*.cpp src/Vk/*.cpp src/Ui/*.cpp src/Service/*.cpp $(IMGUI_CPP_PATHS) $(LDFLAGS)
VulkanDebug: $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS)
g++ $(CFLAGS) -g -o VulkanDebug $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS) $(LDFLAGS)
VulkanOpt: $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS)
g++ $(CFLAGS) -O3 -o VulkanOpt $(OWN_CPP_PATHS) $(IMGUI_CPP_PATHS) $(LDFLAGS)
.PHONY: test clean
run: VulkanRun
LD_LIBRARY_PATH=$(VULKAN_SDK_PATH)/lib
VK_LAYER_PATH=$(VULKAN_SDK_PATH)/etc/vulkan/explicit_layer.d
./VulkanRun
test: Unit_Test
LD_LIBRARY_PATH=$(VULKAN_SDK_PATH)/lib
VK_LAYER_PATH=$(VULKAN_SDK_PATH)/etc/vulkan/explicit_layer.d
./Unit_Test
debug: VulkanDebug
LD_LIBRARY_PATH=$(VULKAN_SDK_PATH)/lib
VK_LAYER_PATH=$(VULKAN_SDK_PATH)/etc/vulkan/explicit_layer.d
optimise: VulkanOpt
LD_LIBRARY_PATH=$(VULKAN_SDK_PATH)/lib
VK_LAYER_PATH=$(VULKAN_SDK_PATH)/etc/vulkan/explicit_layer.d
./VulkanOpt
7 clean:
rm -f VulkanRun
rm -f Unit_Test
rm -f VulkanDebug
rm -f VulkanOpt
I installed cmake using the latest install script for 3.21.0.
I created a CMakeLists.txt in the root of the project as follows :
cmake_minimum_required(VERSION 3.21.0)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17")
project(LanderSim)
file(GLOB_RECURSE SOURCES "src/**.cpp")
add_executable(main ${SOURCES})
find_package(Bullet CONFIG REQUIRED)
if (BULLET_FOUND)
include_directories(${BULLET_INCLUDE_DIRS})
target_link_libraries(main PRIVATE LinearMath Bullet3Common BulletDynamics BulletSoftBody)
endif (BULLET_FOUND)
After many hours of trying I decided to try vcpkg. Following the install instructions from bullet :
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install bullet3
This resulted in errors of
CMake Error at CMakeLists.txt:11 (find_package):
Could not find a package configuration file provided by "Bullet" with any
of the following names: BulletConfig.cmake bullet-config.cmake
Looking in CMakeCache.txt i see "Bullet_DIR:PATH=Bullet_DIR-NOTFOUND"
I found the BulletConfig.make file in "/home/ash/vcpkg/installed/x64-linux/share/bullet3" and in "/home/ash/vcpkg/packages/bullet3_x64-linux/share/bullet3" and set the MakeCache.txt var Bullet_DIR:PATH to these variables (tested one at a time).
Running again I get CMake set_and_check() function not recognised. Or something to that effect. Looking in the BulletConfig.make file I see these set_and_check() functions aren't recognised by the linter. I cant find any information about them being deprecated online but I assume this is the case. So I change to set() and CMake then succeeds and builds its files.
Running make I then get an error.
fatal error: btBulletDynamicsCommon.h: No such file or directory,
#include <btBulletDynamicsCommon.h>
I tried prepending bullet/ to the include path as others had this issue but it causes the same error.
So I must be doing something wrong and I'm obviously not understanding the process that CMake uses to add includes and link libraries. I'm sure, given the popularity of CMake, that there must be something obvious. But I've spent about 10 hours over a few days searching and trying different variations and I'm starting to get very frustrated.
I've bounced off CMake before (hence why I was working with a makefile for months), but I'm determined to do this properly. I just could really use some help if anyone knows how to get CMake to generate a makefile that can see a package installed with vcpkg.
Or indeed if the vcpkg of Bullet is out of date, then a way to link and include it with CMake alone would be great. I just thought vcpkg would be easier as it provides a cleaner file structure by default as well as a CMake config file.
Thanks.
EDIT1
I've used 'cmake .' and 'cmake . -DCMAKE_TOOLCHAIN_FILE=/home/ash/vcpkg/scripts/buildsystems/vcpkg.cmake' to build the makefile. Both result in the same missing headers errors when calling make.
EDIT2
All CMake files were removed from the project (except CMakeLists.txt) before each call to cmake to ensure no values were stored there.
EDIT3
Poked around a bit more. Here is the BulletConfig.cmake file :
#
# BulletConfig.cmake(.in)
#
# Use the following variables to compile and link against Bullet:
# BULLET_FOUND - True if Bullet was found on your system
# BULLET_USE_FILE - The file making Bullet usable
# BULLET_DEFINITIONS - Definitions needed to build with Bullet
# BULLET_INCLUDE_DIR - Directory where Bullet-C-Api.h can be found
# BULLET_INCLUDE_DIRS - List of directories of Bullet and it's dependencies
# BULLET_LIBRARIES - List of libraries to link against Bullet library
# BULLET_LIBRARY_DIRS - List of directories containing Bullet' libraries
# BULLET_ROOT_DIR - The base directory of Bullet
# BULLET_VERSION_STRING - A human-readable string containing the version
set(PACKAGE_PREFIX_DIR /home/ash/installed/x64-linux)
set ( BULLET_FOUND 1 )
set ( BULLET_USE_FILE "${PACKAGE_PREFIX_DIR}/share/bullet3/UseBullet.cmake" )
set ( BULLET_DEFINITIONS "" )
set ( BULLET_INCLUDE_DIR "${PACKAGE_PREFIX_DIR}/include/bullet" )
set ( BULLET_INCLUDE_DIRS "${PACKAGE_PREFIX_DIR}/include/bullet" )
set ( BULLET_LIBRARIES "LinearMath;Bullet3Common;BulletInverseDynamics;BulletCollision;BulletDynamics;BulletSoftBody" )
set ( BULLET_LIBRARY_DIRS "${PACKAGE_PREFIX_DIR}/lib" )
set ( BULLET_ROOT_DIR "${PACKAGE_PREFIX_DIR}" )
set ( BULLET_VERSION_STRING "3.17" )
# Load targets
if(NOT TARGET Bullet3Common)
file(GLOB CONFIG_FILES "${PACKAGE_PREFIX_DIR}/share/bullet3/*Targets.cmake")
foreach(f ${CONFIG_FILES})
include(${f})
endforeach()
set(_DIR)
endif()
As stated before a few of the set functions were set_and_check(). So I changed to set() as apparently cmake 3.21 has no set_and_check() function. After a little testing by printing message(), i found that PACKAGE_PREFIX_DIR was not being set anywhere. So that is why I've set it explicitly in this file. The variables are now set correctly as reported by message() in the CMakeLists.txt file. But still it make cannot find the header files.
EDIT4
I created an empty project and ran through each library I wanted to include. Everything works except for Bullet3. However it does now see the header files. What changed between the two CMakeFiles? Nothing as far as I can tell. I'll need to find out because I have to port this project over but in the meantime this is another issue with the package.
from /home/ash/projects/C++/CMakeImportTests/src/main.cpp:22:
/home/ash/vcpkg/installed/x64-linux/include/bullet/BulletCollision/CollisionDispatch/btCollisionWorld.h:77:10:
fatal error: LinearMath/btVector3.h: No such file or directory
77 | #include "LinearMath/btVector3.h"
I think this is the same issue as described #7877
If i remove all includes of Bullet but leave the CMakeList.txt untouched, we get this error:
[ 50%] Building CXX object CMakeFiles/main.dir/src/main.cpp.o
[100%] Linking CXX executable main
/usr/bin/ld: cannot find -lLinearMath
/usr/bin/ld: cannot find -lBullet3Common
/usr/bin/ld: cannot find -lBulletDynamics
/usr/bin/ld: cannot find -lBulletSoftBody
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/main.dir/build.make:104: main] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/main.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
Is this a clue that some environment variable is not set?
EDIT5
There seems to be an ordering dependency for the target_link_library call. The suggested usage is:
target_link_libraries(main PRIVATE LinearMath Bullet3Common BulletDynamics BulletSoftBody)
Checking bullet.pc in the libs/ directory i found
Libs: -L${libdir} -lBulletSoftBody -lBulletDynamics -lBulletCollision -lLinearMath
So I tried rearranging and following the pattern:
target_link_libraries(main PRIVATE BulletSoftBody BulletDynamics BulletCollision Bullet3Common LinearMath)
Additionally there was also a need to manually link directories.
target_link_directories(main PRIVATE ${BULLET_LIBRARY_DIRS})
This now compiles without error in my test project. It seems LinearMath must be after most of the other libraries (although it can be before Bullet3Common it seems).
For some reason it's still not finding the header files when I copy the exact same CMake commands over to my main project. So I'm not free of this yet.
I should say that I was able to remove the change I made to BulletConfig.cmake of setting PACKAGE_PREFIX_DIR statically.
So just to recap my issue. A small test project works and I can use bullet and number of other libraries that I use in my main project. But if i copy this working CMakeLists.txt to my main project it can no longer find the headers and throws this error :
btBulletDynamicsCommon.h: No such file or directory
8 | #include <btBulletDynamicsCommon.h>
Bullet_DIR:PATH=/home/ash/vcpkg/installed/x64-linux/share/bullet3 is the same in both cases.
After all that.
The set_and_include() error is a known issue and mathisloge over at vcpkg git said the Bullet package needs to be updated. The workaround is to change the calls to set().
The ordering of the target libraries is important. The suggested way in the Bullet vcpkg package is :
target_link_libraries(main PRIVATE LinearMath Bullet3Common BulletDynamics BulletSoftBody)
But this fails to compile. It should be:
target_link_libraries(main PRIVATE BulletSoftBody BulletDynamics BulletCollision Bullet3Common LinearMath)
Also had to tell cmake the link directories using :
target_link_directories(main PRIVATE ${BULLET_LIBRARY_DIRS})
Then I still had header missing errors. But after a restart things just started working again. Hopefully there is enough here to help someone if they hit similar problems.
I'm trying to speed up an optimization routine using MKL's blas implementation in fortran. I need to have the result in a shared library so that it is accessible from a larger script. I can compile and link my code without any warnings, but the resulting .so file has an undefined reference to the blas routine I'm trying to call, namely dgemm.
relevant section of the fortran code:
subroutine sumsquares(params, Mx, flen, glen, numr, numcols, g, lambda, res)
implicit none
integer, intent(in):: flen, glen, numr, numcols
real(8), dimension(flen, numcols) :: params
real(8), dimension(flen, numcols) :: g
real(8), dimension(flen, numcols) :: gc
real(8), dimension(flen, glen) :: Mx
gc = -g
call dgemm('N', 'N', flen, glen, numcols, 1, Mx, flen, params, numcols, 1, gc,flen)
return
end subroutine sumsquares
and the corresponding makefile
FC=ifort
LD_LIBRARY_PATH=/opt/intel/composerxe-2011.1.107/compiler/lib/intel64:/opt/intel/composerxe-2011.1.107/mkl/lib/intel64
LIBRARY_PATH=/opt/intel/composerxe-2011.1.107/compiler/lib/intel64:/opt/intel/composerxe-2011.1.107/mkl/lib/intel64
INCLUDE=/opt/intel/composerxe-2011.1.107/mkl/include
FPATH=/opt/intel/composerxe-2011.1.107/mkl/include
CPATH=/opt/intel/composerxe-2011.1.107/mkl/include
FFLAGS=-i8 -I$(MKLROOT)/include/intel64/ilp64 -I$(MKLROOT)/include
LDFLAGS= -shared -nofor-main -fPIC
LINKLIBS=-fPIC -shared -L$(MKLROOT)/lib/intel64 $(MKLROOT)/lib/intel64/libmkl_blas95_ilp64.a -lmkl_rt -lpthread -lm
sumsquares: sumsquares.f90
$(FC) $(FFLAGS) -c -fPIC /opt/intel/composerxe-2011.1.107/mkl/include/blas.f90 -o blas95.o
$(FC) $(FFLAGS) -nofor-main -c -fPIC sumsquares.f90
$(FC) $(LDFLAGS) sumsquares.o $(LINKLIBS) sumsquares.o
As I said, I can run make without any warnings, but when I run nm sumsquares.so | grep dgemm I see U dgemm_, and when I try to load the .so file, I crash with a segfault (while calling an unrelated subroutine, so I don't think it's related to this code). How do I get the linker to put in the relevant function into the so file?
Update
I am loading the so file in an R script by calling dyn.load in R as follows:
Variation 1:
dyn.load("/home/me/path/sumsquares.so")
Variation 2:
dyn.load("/opt/intel/composerxe-2011.1.107/mkl/lib/intel64/libmkl_rt.so")
dyn.load("/home/me/path/sumsquares.so")
Both variations lead to the same result, with a segfault.
Update # 2
I should point out that intel MKL static libaries are compiled with the -fPIC flag, at least according to the documentation. I clearly don't know what I'm doing, but from what I can tell, something like this should be possible.
As blas is used extensively in scientific computing, I am concerned about collisions with different versions. If I'm linking statically within my so file, and load that so file into a program that uses a different blas implementation, would that lead to a collision, or would my library play nice?
If the library is really static, you cannot put in a shared library. Shared object code is compiled in a different way, so that it can work independent of the position. Flags like -fPIC must be used that are not used for static libraries.
Either compile your BLAS with dgemm as a dynamic library and load it before you load your custom library (perhaps the R dyn.load will load the dependencies automatically, I do not know, you can try) or just include the code of DGEMM into your own library and compile everything together into one .so.
Do not forget you have to use the MKL Linking Advisor https://software.intel.com/content/www/us/en/develop/articles/intel-mkl-link-line-advisor.html Do NOT link with the ILP64 library, unless you know what you are doing and have a good reason to do so.
Also, although most of the MKL is shipped with static libraries built using -fPIC, the Fortran 95 interfaces to LAPACK and BLAS are not. The source files for the interfaces are included, so you need to compile them yourself with -fPIC if you want to use them. They are found at $MKLROOT/interfaces/blas95 and $MKLROOT/interfaces/lapack95.
How do I get the linker to put in the relevant function into the so file?
That's not how shared libraries work; you need to ship the so with your other files (and set the appropriate RPATH), or link to a static version of the library.
When you say:
when I try to load the .so file, I crash with a segfault
This sounds like you're trying to directly dlopen() or something similar; just let the dynamic (runtime) linker do its job.
I'm struggling to link my program on Linux. I've given up and hacked the Makefile I'm using to use an archive group. However, I've still got a bunch of undefined references to things I know I export- the build succeeds on Windows and if I build LLVM from source.
The full command is
g++ -o ../Build/x64/Release/SemanticTest -s -m64 -L/usr/lib64 -L/usr/lib/llvm-3.6/lib -L/opt/wide/boost_1_59_0/stage/lib -L../Build/x64/Release -Wl,--start-group ../Obj/SemanticTest/x64/Release/test.o ../Obj/SemanticTest/x64/Release/main.o -lUtil -lSemantic -lParser -lLexer -lm -lstdc++ -lclangFrontend -lclangSerialization -lclangDriver -lclangTooling -lclangCodeGen -lclangParse -lclangSema -lclangAnalysis -lclangRewriteFrontend -lclangRewrite -lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMBitWriter -lLLVMIRReader -lLLVMAsmParser -lLLVMR600CodeGen -lLLVMipo -lLLVMVectorize -lLLVMR600AsmParser -lLLVMR600Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMLineEditor -lLLVMInstrumentation -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMCodeGen -lLLVMScalarOpts -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -ldl -lpthread -lncurses -lboost_program_options -larchive -lz -Wl,--end-group
How can I convince ld to actually find the stuff I export?
This has something to do with incompatible ABIs. I had old cached binaries lying around that I needed to clear out. I rebuilt my own work with Clang 3.6 and now I can mostly link. There's just functions that use std::string left between my code and my used libraries, namely LLVM&Clang and Boost.
Ultimately, I think this is probably due to all the stuff I did to try to work with both Precise and Willy with the same build scripts, like install Clang 3.6 and try to use that as the compiler. A clean install of Willy doing the obvious thing works just fine.
My link command is:
gcc -O2 -m32 -o ParseInt.exe ParseInt.o hsbracket.o \
-L../../dist/ia32/build -lffi -lHSarray-0.5.0.0-ghc7.8.3 \
-lHSbin-package-db-0.0.0.0-ghc7.8.3 -lHSbinary-0.7.1.0-ghc7.8.3 \
-lHSbytestring-0.10.4.0-ghc7.8.3 -lHSCabal-1.18.1.3-ghc7.8.3 \
-lHScontainers-0.5.5.1-ghc7.8.3 -lHSdeepseq-1.3.0.2-ghc7.8.3 \
-lHSdirectory-1.2.1.0-ghc7.8.3 -lHSfilepath-1.3.0.2-ghc7.8.3 \
-lHSghc-7.8.3-ghc7.8.3 -lHSghc-prim-0.3.1.0-ghc7.8.3 \
-lHShaskeline-0.7.1.2-ghc7.8.3 -lHShaskell2010-1.1.2.0-ghc7.8.3 \
-lHShaskell98-2.0.0.3-ghc7.8.3 -lHShoopl-3.10.0.1-ghc7.8.3 \
-lHShpc-0.6.0.1-ghc7.8.3 -lHSinteger-gmp-0.5.1.0-ghc7.8.3 \
-lHSold-locale-1.0.0.6-ghc7.8.3 -lHSold-time-1.1.0.2-ghc7.8.3 \
-lHSpads-haskell-1.1-ghc7.8.3 -lHSpretty-1.1.1.1-ghc7.8.3 \
-lHSprocess-1.2.0.0-ghc7.8.3 -lHSrts-ghc7.8.3 \
-lHSrts_debug-ghc7.8.3 -lHSrts_l-ghc7.8.3 -lHSrts_thr-ghc7.8.3 \
-lHSrts_thr_debug-ghc7.8.3 -lHSrts_thr_l-ghc7.8.3 \
-lHStemplate-haskell-2.9.0.0-ghc7.8.3 -lHSterminfo-0.4.0.0-ghc7.8.3 \
-lHStime-1.4.2-ghc7.8.3 -lHStransformers-0.3.0.0-ghc7.8.3 \
-lHSunix-2.7.0.1-ghc7.8.3 -lHSxhtml-3000.2.1-ghc7.8.3 \
-lHSbase-4.7.0.1-ghc7.8.3 -Wl,-melf_i386
and I'm getting a bunch of errors like:
ParseInt.o: In function `main':
ParseInt.c:(.text.startup+0x16): undefined reference to `test'
../../dist/ia32/build/libHSrts-ghc7.8.3.so: undefined reference to `base_GHCziWord_W16zh_con_info'
../../dist/ia32/build/libHSrts-ghc7.8.3.so: undefined reference to `base_GHCziConcziSync_runSparks_closure'
../../dist/ia32/build/libHSrts-ghc7.8.3.so: undefined reference to `base_ControlziExceptionziBase_nonTermination_closure'
but the undefined references are defined in the base .so I linked against:
$ nm ../../dist/ia32/build/libHSbase-4.7.0.1-ghc7.8.3.so | grep base_GHCziWord_W16zh_con_info
26690:00550884 T base_GHCziWord_W16zh_con_info
$ nm ../../dist/ia32/build/libHSrts-ghc7.8.3.so | grep base_GHCziWord_W16zh_con_info
104: U base_GHCziWord_W16zh_con_info
So why doesn't libHSrts see things defined in libHSbase? I was following the directions here: http://www.vex.net/~trebla/haskell/so.xhtml, and had ParseInt.exe correctly linking at one point but then I added some libraries to the cabal package / wrote a bunch more Haskell code (ParseInt.c and hsbracket.c did not change).
I've read about linking order (https://stackoverflow.com/a/409470/1542000), and rts is earlier in the link command than the base library it depends on, so I'm not sure why I'm getting undefined references.
I was dumb and missed the obvious: try to fix the first error gcc printed.
I managed to get the test function removed from the exported modules in my cabal package. Upon re-building the cabal package with test added to the .so, all the linking errors went away.
I'm trying to dynamically load a camera library .so file into a Linux executable to gain access to simple camera functions.
I'm attempting to do this by:
if ( (newHandle = dlopen("./libCamera.so",RTLD_LAZY | RTLD_GLOBAL)) == NULL )
{
printf( "Could not open file : %s\n", dlerror() );
return 1;
}
However this fails and I receive the following output:
"Could not open file : libCamera.so: undefined symbol: ZTVN10_cxxabiv117__class_type_infoE"
How do I find out what symbols it is relying on?
Most likely, libCamera.so uses a symbol defined in a shared library without depending on that library.
Find a culprit. Take a real executable which links against libCamera.so (and it works). List its dependencies with ldd /path/to/executable. Among them should be a library which has a definition for ZTVN10_cxxabiv117__class_type_infoE (use grep to select likely candidates, nm -D on a library to be sure). That library won't be in the list shown by ldd ./libCamera.so.
Solve a problem. Load the library found in step 1 by dlopen first (use RTLD_GLOBAL there as well).
If there is a problem with another symbol, goto step 1.
If newly-added libraries have the same problem too, goto step 1.
Tell library authors to please fix their linking.
It could also happen that one of the prerequisites in ldd ./libCamera.so got upgraded and lost a symbol definition (maybe it was recompiled with a compiler which does name mangling differently). Then you won't find the culprit in step 1, and there is no solution but downgrading something again.
The ldd command can be used to display shared library dependencies.
ldd libCamera.so
Once you know the dependencies, you can use nm to show the symbols in each library.
nm -DC libCamera.so
I had a similar problem. It was to do with a .a library, which should have been linked to my .so and statically linked into the archive being left out.
I determined this with (OP object name used here):
nm mylibrary.so | grep ZTVN10_cxxabiv117__class_type_infoE
0000ABC0 U ZTVN10_cxxabiv117__class_type_infoE
The U here means that the symbol is "undefined". You can find the demangled name of the missing object with --demangle:
$ nm --demangle mylibrary.so | grep 0000ABC0
0000ABC0 U abi::class_type_info(params...)
(or something like that) this should help you figure out which library is missing.
In my case, even after including the library on the compiler line I still had the issue. Eventually, after some tinkering I discovered that the library-file (.a) has to come after its dependent object (.o) file like:
g++ -Wl,-E -g -m32 ... -fPIC myobjects1.o myobjects2.o missing_library.a -shared -o mylibrary.so
Now I get (no more U):
$ nm --demangle mylibrary.so | grep 0000ABC0
0000ABC0 T abi::class_type_info(params...)
and most importantly I don't get the error any more!
In your source code for libCamera.so, you have unresolved external symbol. It means that type_infoE have no definition in your source code and should be resolved.