I pulled out an application that I wrote in C++ using the sfml library, but I'm having trouble setting up the library in Eclipse. I specified the include path, the lib path and included all the necessary .so libraries to link to. the application compiles fine but it complains at runtime about missing libraries. Why is this happening? Didn't I include the path to the libraries in the project settings already? I have even tried to place all the .so's in the executable directory with no luck.
There is only the name of the shared lib stored in the executable. At program startup the dynamic linker then searches for the specified libs in its search paths. You can add/specify search paths by placing them colon separated in the environment variable LD_LIBRARY_PATH or by specifying them in /etc/ld.so.conf (at least if you use some unix based OS). On windows the whole PATH environment variable is used when searching for dynamic-link libraries (DLL).
To see the paths of shared libraries used by a given application run ldd applicationPath.
Related
I have a question related to how to install a built executable program with cmake when it relies on some external libraries. Suppose my executable is abc, and it relies on two external libraries: lib1.so and lib2.so. The structure of the codes are as follows:
-.........
|----bin (lib1.so lib2.so)
|----include(lib1.h lib2.h)
|----src(main.cpp)
When the executable program is installed using the following cmake commands:
INSTALL(TARGETS ${Exe_Name}
RUNTIME DESTINATION Path to bin
LIBRARY DESTINATION Path to bin)
I expect that the executable program will be in the same directory with lib1.so and lib2.so. However, when I execute the built program in the installation folder, I met the following error:
error while loading shared libraries: lib1 can not open shared object file No such file or directory
If I use ldd to check the executable, I found lib1.so and lib2.so not found. After searching for possible solutions, I found if I call the executable in this way, then it worked:
LD_LIBRARY_PATH=./ ./my_program_run
Then my question is how I can let my executable program knows the locations of the shared libraries with cmake when it is installed? Thanks.
This is best solved this with the RPATH of the final executable. RPATH is a hardcoded search path for the executable itself, and allows the use of the string $ORIGIN, which expands to the location of the executable at runtime. See this reference: http://man7.org/linux/man-pages/man8/ld.so.8.html
CMake strips the rpath of a binary at installation time, to avoid the binary picking up libraries littered around your development tree. But it also provides a simple way to modify the installation rpath for exactly this reason. Here's the short answer:
IF(UNIX)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:\$ORIGIN/../bin:\$ORIGIN")
ENDIF()
This particular example appends to the existing rpath, and adds . and ../bin to the search path, all relative to the location of the binary.
Some developers claim that adjusting the RPATH of the binary is not a good idea. In the ideal world, all the libraries would live in the system library directories. But if you take this to the extreme, you end up with Windows (at least the older ones), where c:\windows\system32 is full of junk that came from who knows where, and may or may not conflict with other software, etc. Using rpath and installing everything in one place seems like a great solution.
If the application is to be cleanly installed to a standard linux distribution, then you should either install the supporting shared libraries into a standard location (/usr/lib), or you should add the libraries location to the ld.so config, by create an /etc/ld.so.conf.d/myprogram.conf file containing the name of the directory the libraries are in.
If the installation is temporary or more ad-hoc, then a script to set the LD_LIBRARY_PATH is suitable.
The libraries are searched in the predefined locations which includes standard library paths configured with ld.so.conf and LD_LIBRARY_PATH. You can also try to compile your app with -rpath, but it is not recommended by some developers. I suggest you to create a wrapper script which will set LD_LIBRARY_PATH and run the real application like that:
"theapp" script:
#!/bin/sh
dir="`dirname \"$0\"`"
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$dir"
exec "$dir/theapp.real" # your real application
The application, script and libraries should be in the same location (under bin/).
I have some problems with linking my macOS app against C libraries.
I have several question related to this issue.
It is better to link app against dynamic or static libraries taking into account that this will be very custom libraries rather not shared with other apps?
I have linked my macOS Xcode app against ~14 static libraries .a and it works fine. I have reconfigured CMakeLists.txt making this libraries and now Xcode project doesn't work. The main change was changing the directory I have
"$(SRCROOT)/../../c/<project_name>/outputs/lib/apple/static"
But now I have both static (.a) and dynamic (.dylib) libraries in the same path
"$(SRCROOT)/../../c/server/outputs/lib/apple"
I don't know whether this should matter, but linking against static libraries causes that after running my Xcode project it complains that it cannot load lib.dylib So maybe it finds this dynamic library under Library Search Paths and tires to load them but don't find them linked?
So I tired to link Xcode macOS app against .dylib libraries and instead of static .a libraries added them in Link Binary with Libraries. The problem is that the error not finding library now also occurs.
Maybe I should change something here ? But what If I will distribute my app to some other computers that will not have libraries in this specific location. How can I include dynamic libraries in Xcode bundle in order to be always findable.
I know I added maybe to many question. But would like to know how to the best solve this issue? Better to link statically or dynamically and then how to correctly achieve this avoiding this error.
UPDATE
It seems that when linking against .dylib it only works when I add path to this library directory to Runpath Search Paths.
It also seems that when I link against static library .a it works when .dylib isn't in the same directory (I moved .a library into /static subdirectory) and then for this moved library error isn't showing any more. But isn't there way to link statically when there is .a and .dylib libraries inside the same directory?
I know this is an old question but it's one of the top results when searching google for "Xcode static linking."
I recently encountered this issue when integrating with Intel IPP, which puts static and dynamic libs in the same directory.
If I used the standard Xcode linking method of adding the library via the "Build Phases | Link Binary with Libraries," Xcode translated that UI into a command line that looked like this:
clang++ ... -L/my/path -lstatic1 -lstatic2 ...
But that causes the linker to prefer the DLL instead of the static library in the same directory.
I worked around this by removing the entries from the "Build Phases | Link Binary with Libraries" window, and adding full relative paths to the libraries in the "Build Settings | Other linker flags" entry:
../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic2.a
This caused Xcode to translate the UI into a command line that looked like this:
clang++ ... ../../path/to/lib/libstatic1.a ../../path/to/lib/libstatic1.a ...
Which linked the libraries statically.
Finally, I have linked this Xcode macOS project with multiple dynamic C libraries (.dylib).
REMARK
In order to link with static libraries (.a) They cannot be placed side by side with dynamic libraries! path/project_name/outputs/lib/apple/*.dylib and then place static libs under path: path/project_name/outputs/lib/apple/static/.a As XCode tries to link dynamic libraries if they found them on Libraries Search Path in Build Settings.
DYNAMIC C LIBRARIES LINKIN IN XCODE
Add dynamic libraries to Build Phases tab and Link Binaries with Libraries section as on the image
Embed all this dynamic libraries in output macOS Application Wrapper
You get something like this:
Then in Build setting add Libraries Search Paths
And finally add Runtime Search Paths in Build Settings
I have built a cross-platform C++ application that uses some external libraries (e.g. Boost, GLFW). My intention is to create an archive, for instance a .zip file, for each operating system so that the end user only has to extract this package in order to run the application. I am facing a problem related to dynamic linking of the libraries.
When I built the application in Linux, I use the -Wl,rpath option to specify the run time library search path. On Windows, I can simply place all relevant .dll files in the same folder as where the executable resides. Now on MacOS, I am facing the issue that the libraries are referred to by absolute paths. Those paths may be valid for my system, but not necessarily for the system of the user. I already found that I can change those paths to relative paths using install_name_tool.
The remaining difficulty is that I have to change quite a lot of these references. Besides the references in the executable, some of the libraries have dependencies themselves which are also defined by absolute paths.
My question is: Is there an efficient and smart way to set relative paths instead of absolute paths for the libraries on MacOS?
I have 3rd parties libraries that don't placed under "/usr/lib".
I defined their path in eclipse library search path .
The project compile and linkage well, but when i run project i got exception that library doesn't found.
if i copy the 3rd party library to "/usr/lib" than it run ok.
I believe that this is path issue (i am new to cpp), how do i configure this in eclipse ?
Thank you
First of all, since it's crashing during runtime, you are linking against dynamic libraries (libWhatever.so), so you have to add your library path to the LD_LIBRARY_PATH environment variable. Otherwise, you could force the linker to link statically to static libraries (libWhatever.a), using the -static flag.
I am trying to get my head around the way shared libraries work in the c++ unix environment. I understand we only need header files and no shared libraries specification when compiling code. But if I want to create an executable or shared library from my compiled files, do I need to specify shared library dependencies (those are dynamic)? And do the paths of shared libraries need to match the path at runtime loading?
I am using Linux 2.6.18-164.11.1.el5 #1 SMP x86_64 GNU/Linux
I am having a problem where my code is not able to pick up a library at runtime. I have tried setting LD_LIBRARY_PATH and PATH. But at runtime when I run the executable, I get the following error:
Error: librc.so: cannot open shared object file: No such file or directory
Sam
The headers are only for the compile phase. At link time, you usually have to specify which shared libs you are going to link to. You might see -L options to set locations to where shared libraries reside, and/or -l to specify which libraries to link. There is usually also a switch on the command line to alert the linker as to whether you are using thread-safe versions of the libs or the 'regular' ones, and another switch to specify dynamic linking.
At run time, whether you are starting the program that uses the libs, or running ldd to find out what it needs, the OS has a system for locating .so files, and this can vary from one unix version to another. The LD_LIBRARY_PATH variable specifies where to look for .so files, but may not be the full story, depending on the exact unix version in question. Also, you probably don't want to fiddle around with modifying LD_LIBRARY_PATH except from a throw-away shell, since it has system wide effects. A better option is to check it the 'missing' .so files are or are not on the existing path set by LD_LIBRARY_PATH, and if not, try putting copies of them somewhere on that path.
At run time, dynamic libraries are searched:
in a path recorded in the executable (under linux with -rpath at link time, under Solaris with -R, using $ORIGIN in a directory name allows to specify a directory relative to the directory containing the executable)
in the LD_LIBRARY_PATH (or equivalent, there are sometimes 64/32 bits variant). If a path has been recorded in the executable, LD_LIBRARY_PATH may not searched (under Linux it is searched after the recorded path if the executable has been linked with the option --enable-new-dtags; I don't remember Solaris behavior for now)
in a set of system dependant directories (Linux allows to specify them in /etc/ld.so.conf and has a cache, see ldconfig)