I know ldd can only take a binary as its parameter what I am asking here is how to run ldd with a binary, say, mybin, with parameter of the binary. For instance, mybin --myparam ./configfile.conf.
The linker will differ if I add the conf file for my binary because it loads some plugins in runtime with the plugins' shared object files, plugin1.so something like this. I have some undefined reference issue but I still got no idea which .so file I was missing.
If I run ldd ./mybin, everything is linked and running the plain binary is fine. Once I add the conf file for my binary, to let it loads some plugins shared library, then my binary will report errors when loading those library(coded exception throw, with some undefined reference error messages).
So if there is way to run ldd with mybin --myparam ./a.file something like this would help a lot.
Use the LD_DEBUG environment variable for this. To see the relevant options, run any command with LD_DEBUG=help. For example, running LD_DEBUG=help ls on my machine gives this output:
LD_DEBUG=help ls
Valid options for the LD_DEBUG environment variable are:
libs display library search paths
reloc display relocation processing
files display progress for input file
symbols display symbol table processing
bindings display information about symbol binding
versions display version dependencies
scopes display scope information
all all previous options combined
statistics display relocation statistics
unused determined unused DSOs
help display this help message and exit
To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
One way of debugging your dlopens, or whatever late loading mechanism you are using, would be to run your executables with the relevant args with LD_DEBUG=all. This would give you a lengthy output detailing symbol lookups and search paths. This output would also tell you about resolution failures.
Related
I am working on a C++ project consisting of multiple similar programs. Each use a variety of headers and binaries, around 80. I managed to compile each program, and successfully run each but one of them, one named VerifyServer. When I try to run this, I get the below error:
./VerifyServer: error while loading shared libraries: libboost_system.so.1.57.0: cannot open shared object file: No such file or directory
However, here's the weird thing:
I was getting a very similar error when I tried running the other programs as well, but then I added
-Wl,-rpath=$(BOOST_LIB_HEADER_PATH)/stage/lib
to each of my compiler arguments, and it worked. I managed to run each programm, and even the file indicated in the error message of VerifyServer changed. Note that the variable BOOST_LIB_HEADER_PATH is correctly assigned to the path of my boost libraries.
Since my run time linker was failing to find this binary to correctly link it with my program, I tried checking which dependencies it was unable to find, so when I ran
ldd VerifyServer | grep boost (I use grep for simplicity)
I get this message:
libboost_thread.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_thread.so.1.57.0 (0x00007f34c9b36000)
libboost_serialization.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_serialization.so.1.57.0 (0x00007f34c9ad1000)
libboost_system.so.1.57.0 => not found
So, by now I assume that the system binary is not in the same directory as the others. When I manually check, I see that oddly enough, it is right there! So I decide to do the same thing on one of the programs that run without any problems, and I use
ldd IdentityProviderServer | grep boost
and I get the following message:
libboost_thread.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_thread.so.1.57.0 (0x00007f97b6094000)
libboost_serialization.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_serialization.so.1.57.0 (0x00007f97b602f000)
libboost_system.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_system.so.1.57.0 (0x00007f97b602a000)
libboost_filesystem.so.1.57.0 => /path/to/boost_1_57_0/stage/lib/libboost_filesystem.so.1.57.0 (0x00007f97b600d000)
When I see that the system binary can be found in the same location as others, I just get confused. I don't know what the issue is here. Is there something I am missing about how the linker works?
Please note that I have to use the version 1.57.0 of boost here. I cannot update it to the current version, and I doubt my issue has anything to do with the version of boost.
This may be due to the linker unable to find transient dependencies. If you are directly linking against EG: libboost_thread, then the applications runtime linker will use the -rpath path that you defined when compiling.
HOWEVER, the libboost_thread may require ITS OWN library, libboost_system. The question is, should the libboost_thread library's runtime linker use your applications -rpath? or ignore it and use its own system search paths?? You must explicitly tell the runtime linker what it should do. Note, the default runtime linker search behavior changes depending on your compiler version. Google, RUNPATH vs RPATH and -Wl,--disable-new-dtags
I have answered this issue in another similar question: CMake project fails to find shared library
Although that user is using CMake to build their application, the underlying problem may be occurring here too.
I have a weird problem on Ubuntu Linux 18.04 that appeared after having run pytest a couple of times. The project is mostly c++, but it also generates pybind11 bindings and generates library files via CMake.
My goal is to force a program to output its files into a specific directory within the project folder, i.e. not in the same directory where the executable file is. I used to achieve that by running this command:
user#computer_name:~/Dev/project$ (cd /home/user/Dev/project/unittests/test_output && "/home/user/Dev/project/./executable" -pdbin /home/user/Dev/project/unittests/test_data/3v8x.pdb -mtzin /home/user/Dev/project/unittests/test_data/3v8x_phases.mtz && cd /home/user/Dev/project)
This command used to work as intended, until today, when I ran some instances of pytest. While pytest is able to complete all tests successfully, my aforementioned command does not work anymore and gives me this error:
user#computer_name:~/Dev/project$ /home/user/Dev/project/./executable: symbol lookup error: /home/user/Dev/project/./executable: undefined symbol: _ZN7library7Class11functionEv
However, when I try to execute the executable in the build directory, like this:
user#computer_name:~/Dev/project$ ./executable
There is no error whatsoever and if I try to give the program its input, the program works as intended without any errors. However, it outputs the files in the build directory - the place where I don't want the output to go.
For further confirmation, I tried to execute the program from another directory again without giving it any input:
user#computer_name:~/Dev/project/unittests$ .././executable
to be greeted yet again with this error:
.././project: symbol lookup error: .././project: undefined symbol: _ZN7library7class11functionEv
So far I've tried to rebuild entire project, generate new Makefiles etc.
I also confirmed that there are no issues with the program itself. Any ideas on how to fix this issue or alternative ways to direct output to different folder without having to pass specific output arguments to the program itself?
If you want executable to pick up the libexecutable.so next to it, you have two options:
Configure LD_LIBRARY_PATH to contain /home/user/Dev/project.
This will make the dynamic linker search there before any other configured directories.
Either do this globally or in a wrapper script.
Compile executable with an rpath. This will make library lookups by executable look in the rpath first. If you pass the -Wl,-rpath,'$ORIGIN'/.. flag (note the single quotes around $ORIGIN!), the dynamic linker will always find libexecutable.so next to executable first.
I'm trying to build a simple C++ project (an executable) that calls a Haskell function,
using Shake for the build script and calling Stack from within the script to build the Haskell library.
Let's say the Haskell library is called haskell-simple-lib.
The shake script calls stack install haskell-simple-lib which outputs an .so file: libHShaskell-simple-lib-*version*-*unique identifier*.so
My Shake rules depends on filenames, and so I can't use the aforementioned name as I don't know in advance what the unique identifier will be. And so, the Shake script runs a cp on the file to _build/libHShaskell-simple-lib.so
The link options for the C++ executable has -L_build and -lhaskell-simple-lib.
When I try to run the executable I get an error saying:
error while loading shared libraries: libHShaskell-simple-lib-0.1.0.0-8DkaSm3F3d44RUd03fOuDx-ghc7.10.2.so: cannot open shared object file: No such file or directory
But, if I rename the file I copied to _build, to the original name that stack install outputted (the one with the unique identifier), the executable runs correctly.
One would think that all I need to do is to simply cp the file to _build without erasing the unique identifier from the name, however I need to know the name of the .so file in advance for the shake script.
I don't understand why when the executable is run the original .so filename is searched for. The link flag doesn't mention the fullname of the .so that stack install outputted, only libHShaskell-simple-lib.
Could it be that the original name is embedded in the .so file? If so, how does one go about solving this issue?
EDIT:
I'm aware this could be solved using a dummy file, but I'd like to know if there's a better way to do this.
The original identifier is embedded in the .so. I don't remember all the details, but I do know that I've solved such problems using rpath twiddling in the past.
While running the application developed by other person, getting the following error
./appln: error while loading shared libraries: libxerces-c.so.28: cannot open shared object file: No such file or directory
And if I run ldd command:
# ldd appln
linux-gate.so.1 => (0x00e20000)
libdl.so.2 => /lib/libdl.so.2 (0x00a61000)
libxerces-c.so.28 => not found
I already have that libxerces-c.so.28 file in current folder. Please help me how to resolve that error
You need to put libxerces-c.so somewhere in the library path. Probably current folder is not searched for libraries. Try putting it in /usr/local/lib
Evidently "the current folder" isn't in the run time search path used by your executable. I'm assuming that you are on linux (linux-gate.so.1).
You need to ensure that "the current" directory is under the search path. You can do this at link time by using the -rpath option to the linker (-R is also accepted) or -Wl,-rpath,<dir> if you are invoking the linker through the compiler front end. This embeds a search path to be used at run time into your program.
Consider how you want the program to be installed, though. There's no point in adding a path that is specific to your development environment. You might want to consider using $ORIGIN or a $ORIGIN relative path which tells the run time linker to look for shared objects in the location containing (or relative to) the executable. You should always avoid adding . to the run time search path; your program shouldn't behave differently depending on the current directory of the process which invokes it.
As a temporary measure you can set the environment variable LD_LIBRARY_PATH to override the embedded and system search paths but it is normally a bad idea to rely on LD_LIBRARY_PATH overrides for a final installation.
By default .so files are NOT being searched in the current folder (they should be in /usr/lib, etc).
To add the current directory for .so lookup use:
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ./appln
When adding new "local system" libraries (e.g. in /usr/local/lib/) you better add that directory (/usr/local/lib/) once in your /etc/ld.so.conf and you should run ldconfig to update the linker cache (every time you add something inside /usr/local/lib/)
See ldconfig(8), ld.so(8), ldd(1), dlopen(3)
If you want your own libraries, set LD_LIBRARY_PATH to a directory containing them (e.g. $HOME/lib/ and to standard directories, e.g.
export LD_LIBRARY_PATH=$HOME/lib:/usr/lib:/usr/local/lib
in your ~/.bashrc (but I dislike that confusing practice, and prefer to manage my /usr/local/lib/).
You could also use some -Wl,-rpath argument but I really dislike that also.
Read also Program Library HowTo and Drepper's paper: How To Write Shared Libraries
I am compiling an application which consists of several projects, that generate dynamic libraries (Shared Libraries on LINUX). Of course that different projects are linking to the others that I've compiled. I am using CodeBlocks 10 under Ubuntu, using GCC compiler.
Due to the fact that, according to the arguments specified by the user, different libraries shall be loaded, in my main application I am loading the appropriate library, according to the decision, with the following line:
dll = dlopen("my_library.so", RTLD_LAZY);
As specified in documentation, the dlopen loads libraries automatically If the library has dependencies on other shared libraries and the process is done recursively.
The problem is that right after my dlopen, I call dlerror() in order to understand what's going on and I get the following error:
../../../../gccDebug/os.so : Cannot open shared object file: No such
file or directory.
Just looking at the error, I completly understand it, because it is looking 2 folders below more than it should. The question is why?
What I mean is: I use relative paths to explicitly load Shared Libraries on the projects. On my Main Application, the Working Directory is ../../gccDebug.
I load, using dlopen, mylibrary.so, which explicitly loads (in project Options) ../../gccDebug/gui.so. This gui.so then also explicitly loads (in project options) ../../gccDebug/so.os
What it seems to me that is happening, is that he is appending the paths making that on the 3rd "iteration" he is looking for a path which is already searching too many folders back than it should. If the first recursive loading (gui.so) works just fine, why does the 2nd recursive loading (so.os) is giving a strange path??
What is wrong with the recursive loading of the shared libraries using dlopen function?
Each path should be relative to the library doing the loading, so for ../../gccDebug/gui.so to load something in the same directory it should load ./gui.so
The extra ../.. are because you've told something in ../../gccDebug to load something in ../../gccDebug_relative to itself_ which relative to your program's working directory is../../gccDebug/../../gccDebugi.e.../../../gccDebug`
Do that a few times for different libraries and you'll get the number of unwanted .. components you're seeing.
Are you sure that gui.so actually loaded? Could it be that mylibrary.so had copied the ../../gccDebug/os.so dependency from gui.so at link-time and so at run-time was trying to load that before loading gui.so?
Have you use ldd mylibrary.so to see what it tries to find? You can also use readelf -d mylibrary.so to see the contents of the dynamic section of the library.