Here’s what I have in my CMakeLists.txt:
link_directories( "/usr/local/lib" )
include(CheckLibraryExists)
CHECK_LIBRARY_EXISTS( "libmali-midgard-t76x-r9p0-r0p0.so" "gbm_create_device" "" MALI )
Result:
Looking for gbm_create_device in libmali-midgard-t76x-r9p0-r0p0.so - not found
The symbol exists in that library:
$ nm -D /usr/local/lib/libmali-midgard-t76x-r9p0-r0p0.so | egrep gbm_create_device
001b245c T gbm_create_device
Why cmake doesn't find that?
It was dependencies.
CHECK_LIBRARY_EXISTS is much more complex than nm -D. CMake actually creates a C project that references that library, and tries to link it.
I missed some dependencies used by that library (libdrm-dev, libxcb-dri2-0, libx11-xcb-dev), so the linker failed.
Resolved by looking what’s in CMakeFiles folder, it contains much more detailed logs.
Related
I have to import a libft4222.so.1.2.3 into a CMake project on Linux. There are no symlinks without version information like a plain libmyimportedlibrary.so. I am writing a FindLibFT4222.cmake to make the library usable in my project.
In my project, a shared library uses libft4222 like this:
if (LIBFT4222_FOUND)
if (NOT TARGET LibFT4222::LibFT4222)
add_library(LibFT4222::LibFT4222 UNKNOWN IMPORTED)
set_target_properties(LibFT4222::LibFT4222
PROPERTIES IMPORTED_LOCATION ${LibFT4222_LIBS})
target_include_directories(LibFT4222::LibFT4222
INTERFACE
${LibFT4222_INCLUDE_DIR})
endif()
endif()
LibFT4222_LIBS points to the imported location of the libft4222.so.1.2.3:
/path/to/libft4222.so.1.2.3
I am adding this library as a dependency to a shared library A in my project.
Finally, I have an executable depending on A.
When I link the executable, the linker reports an error that it cannot find libft4222.so
When I add libft4222 directly to the executable, it works.
The error message I get:
/usr/lib/gcc-cross/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld: warning: libft4222.so, needed by libSomeOtherLib.so, not found (try using -rpath or -rpath-link)
How do I tell CMake to correctly handle libft4222.so.1.2.3 and not to omit .1.2.3?
Update 1: I looked at the SONAME property of libft4222.so.1.2.3:
$ arm-linux-gnueabihf-objdump -p libft4222.so.1.4.4.44 | grep SONAME
SONAME libft4222.so
So I guess creating the symlinks is unavoidable.
I'm trying to cross compile a rust project with cross. My project depends on libcurl. The linker can find the libcurl .so but not the libraries which it depends on:
I'm running:
cross build -vv --target=arm-unknown-linux-gnueabihf
which gives me:
= note: /usr/arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: warning: libnghttp2.so.14, needed by /usr/lib/arm-linux-gnueabihf/libcurl.so, not found (try using -rpath or -rpath-link)
I've already confirmed that the library its looking for exists:
root#80a13d68ad84:/# find /usr/lib -name "libnghttp2.so.14"
/usr/lib/x86_64-linux-gnu/libnghttp2.so.14
/usr/lib/arm-linux-gnueabihf/libnghttp2.so.14
I've read about rust build scripts here, where I can add paths to the library search path, but that has not resolved the issue, this is what my build.rs looks like:
fn main() {
println!("cargo:rustc-link-search=native=/usr/lib/arm-linux-gnueabihf");
}
The error suggests using -rpath or -rpath-link, so how do I configure the rpath in rust? Or is there a different way to resolve this issue?
You might be able to specify linker arguments by using an environment variable like
RUSTFLAGS="-C link-arg=--rpath=..."
Cargo allows placing the same kind of flag in the configuration file (see here) but I'm not sure if cross has the same support for something like that.
I am working on a package which includes C code from third-party library (SUNDIALS). The package compiles and works (i.e., is able to solve a test ODE) with the following Makevars file performing static linking
CXX=clang++
PKG_CPPFLAGS = -I../inst/include
PKG_LDFLAGS = /usr/local/lib
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) $(PKG_LDFLAGS)/libsundials_cvode.a $(PKG_LDFLAGS)/libsundials_nvecserial.a
However, a slightly modified version (based on the example in R-Exts, i.e. -
PKG_LIBS = -L$(XML_DIR)/lib -lxml2) of Makevars (below) fails
CXX=clang++
PKG_CPPFLAGS = -I../inst/include
PKG_LDFLAGS = /usr/local/lib
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) -L$(PKG_LDFLAGS) -lsundials_cvode -lsundials_nvecserial -lm
fails with the following error message.
Error: package or namespace load failed for ‘Rcppsbmod’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcppsbmod/libs/Rcppsbmod.so':
dlopen(/Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcppsbmod/libs/Rcppsbmod.so, 6): Library not loaded: libsundials_cvode.3.dylib
Referenced from: /Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcppsbmod/libs/Rcppsbmod.so
Reason: image not found
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcppsbmod’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/Rcppsbmod’
Exited with status 1.
I am not sure why it is looking for the libraries in another location when I am specifying PKG_LDFLAGS as /usr/local/lib.
As an aside, the test example which comes which the SUNDIALS package compiles and works with the following command
gcc -Wall cvRoberts_dns.c -o cvRoberts_dns.exe -I/usr/local/include -L/usr/local/lib/ -lsundials_cvode -lsundials_nvecserial -lm
So, I know that the library is installed properly and correct files (for linking) are available at /usr/local/lib location.
The entire package source code can be found at - https://github.com/sn248/Rcppsbmod
Any help or guidance will be highly appreciated!
System-wide dynamic linking, as in your second use case which fails, requires the cooperation of the dynamic linker on your system.
That means after build and copyring the libraries to /usr/local/lib you must typically run sudo ldconfig to update the linker cache.
You can check if the libraries are know by grep'ing through the output of ldconfig -p. On my system, no sundials:
edd#rob:~$ ldconfig -p | grep sundials
edd#rob:~$
Relatedly you can (locally) use different directories by declaring them in
/etc/ld.so.conf.d/somefile.conf -- but that is of course not portable and would not help you with a package designated for CRAN.
The use of static libraries you build as part of your package as in your first example would work as it does not require any system assistance. It just takes longer the build the libraries each time.
I am fighting with similar issues, c.f. Runtime linking R-extension on MacOS. My current workaround is to set the rpath at compile time. In your case that would mean:
CXX=clang++
PKG_CPPFLAGS = -I../inst/include
PKG_LDFLAGS = /usr/local/lib
PKG_LIBS= $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) -L$(PKG_LDFLAGS) -lsundials_cvode -lsundials_nvecserial -lm -Wl,-rpath,$(PKG_LDFLAGS)
However, this does not fix your problems. Comparing the error messages I see one difference: In your case the library libsundials_cvode.3.dylib is not found, while in my case it is #rpath/libaf.3.dylib. This means that the library you installed identifies itself as libsundials_cvode.3.dylib. You can check this with
$ otool -L /usr/local/lib/libsundials_cvode.3.dylib
/usr/local/lib/libsundials_cvode.3.dylib:
/usr/local/opt/sundials/lib/libsundials_cvode.3.dylib (compatibility version 3.0.0, current version 3.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
In your case the second output line should not contain an absolute path but only the basename of the library. My installation uses brew, which typically uses absolute paths as library names. In some trivial tests I had no problem with linking an R extension with these libraries.
I see several possibilities:
Try SUNDIAL from brew.
Adjust the library path in your installed libraries with
install_name_tool -id /usr/local/lib/libsundials_cvode.3.dylib /usr/local/lib/libsundials_cvode.3.dylib
to use absolute paths.
Adjust the library path in your installed libraries with
install_name_tool -id '#rpath/libsundials_cvode.3.dylib' /usr/local/lib/libsundials_cvode.3.dylib
and set rpath as above.
Adjust the name of the library your R extension is looking for with this addition to Makevars
all: $(SHLIB)
#if command -v install_name_tool; then install_name_tool -change libsundials_cvode.3.dylib /usr/local/lib/libsundials_cvode.3.dylib $(SHLIB); fi
I'm having trouble trying to do something seemingly very simple with CMake 2.8.11.2 . I have a folder with two files:
-- CMAkeLists.txt --
add_executable(test test.c)
target_link_libraries (test somelib)
-- test.c --
// Some c code
when I create a build directory and issue cmake .., cmake runs with the following output:
C:\Users\Enis\workspace_kepler\tmp\build>cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Enis/workspace_kepler/tmp/build
And an MSVC 2012 solution is generated inside the build folder (as I have MSVC2012 installed). Now, the problem is that when I open that solution and check the linker configuration of the test project under Properties->Configuration Properties->Linker->Input->Additional Dependencies I see that somelib is added as ;-lsomelib.lib and visual studio doesn't like that. It links successfuly only if I change that to somelib.lib manually.
What am I doing wrong? Why does CMake make such a simple mistake? What can I do to change the prefix it generates?
I faced the same issue. The root of the problem is CMAKE_LINK_LIBRARY_FLAG but I have no idea what sets it. Resetting it, demonstrated in the snippet below, should help you.
set(CMAKE_LINK_LIBRARY_FLAG "")
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.