The GDB is built on RHEL-4.7. I run the GDB on RHEL-6.3. If the GDB is dynamically linked, everything works OK. If the GDB is statically linked, I got
(gdb) target remote :2107
localhost: unknown host
:2107: No such file or directory.
When GDB is built statically, we got a warning message:
warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
I also searched with google, it seems that gethostbyname depends on the glibc library. I tried to install the compatible glibc library on RHEL-6.3. But there's no luck. Any hint?
Related
I'am using gdbserver and gdb on host to debug arch ARM application linked to shared library.
I have a copy of the Library on host with symbols and I want gdb to load the local library instead of the remote one.
Changing the sysroot from target: to local path cannot solve the issue. Always gdb load Library from target.
My question is how can I force gdb to use local library iso the remote one ?
I am trying to do is produce a static MPI executable for Linux machines. The source code is written in C++. When I compile serial versions of the code, with gcc -static, and run ldd on the executable it shows no libraries.
However, when I try this with MPI, there are certain libraries that are not being statically linked. I have built my openmpi on my machine with see below shell commands. I also see that the exact same libraries that are not statically linking with the executable are not statically linking to the openmpi build. At the end of the openmpi build, I get
/home/bevan/Downloads/openmpi-4.0.1/opal/.libs/libopen-pal.a(dl_dlopen_module.o): In function `dlopen_open':
dl_dlopen_module.c:(.text+0x413): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/bevan/Downloads/openmpi-4.0.1/orte/.libs/libopen-rte.a(plm_rsh_module.o): In function `setup_launch':
plm_rsh_module.c:(.text+0xca2): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/bevan/Downloads/openmpi-4.0.1/opal/.libs/libopen-pal.a(if.o): In function `opal_ifaddrtoname':
if.c:(.text+0x1e4): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/bevan/Downloads/openmpi-4.0.1/orte/.libs/libopen-rte.a(ras_slurm_module.o): In function `init':
ras_slurm_module.c:(.text+0x6e4): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/bevan/Downloads/openmpi-4.0.1/opal/.libs/libopen-pal.a(evutil.o): In function `evutil_unparse_protoname':
/home/bevan/Downloads/openmpi-4.0.1/opal/mca/event/libevent2022/libevent/evutil.c:758: warning: Using 'getprotobynumber' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
The sort of command chain I feel I should be using is,
tar -xvf openmpi-4.0.1
cd ./openmpi-4.0.1
./configure --prefix="$HOME/.openmpi" --without-memory-manager CXX=g++ CC=gcc LDFLAGS=--static --disable-shared --enable-static
make
sudo make install
export PATH="$PATH:$HOME/.openmpi/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$HOME/.openmpi/lib/"
cd application/directory/build
cmake ..
make application
I would like to be able to run ldd application after compiling with MPI and have no dynamically linked libraries associated with the application.
I am loading a core file into GDB inside a docker container with alpine linux.
Initially my gdb complained about binary not found, then i followed this discussion gdb During startup program exited with code 127 and installed libc6-compat, even though I have a 64-bit linux and my interpreter for the binary is 64-bit [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
That actually worked but now i get the same error for the .so files. I can see that .so files are in the path set on solib-search-path but gdb did not load any of the libraries and complains No such file or directory.
binary runs on a production host where the libraries are in the path
I am running the binary on a development host by setting the solib-search-path
ldd binary says libraries not found which is expected since this is a development host
binary runs on a production host where the libraries are in the path I am running the binary on a development host by setting the solib-search-path
There is your problem right here.
The solib-search-path is the path where GDB will look for libraries.
In no way does that setting affect the binary itself, which uses either standard system library path, compiled-in DT_RPATH, or LD_LIBRARY_PATH environment variable to search for shared libraries.
Usually, solib-search-path should only be set when you are analyzing a core dump that came from some other host (GDB needs access to the exact libraries that were used when the core dump was generated). Setting solib-search-path while running a local binary should never be ncessary -- GDB can automatically deduce where the libraries are by asking the runtime loader where they are.
ldd binary says libraries not found which is expected since this is a development host
If ldd says that, then of course you will not be able to run the binary (inside of outside GDB).
I am using X-server on Linux tutnix 3.13.0-30-generic #54-Ubuntu i686 i686 GNU/Linux .
On X-server i am using schroot to change the root and after that I run my application on it.
Now the problem is I am trying to run gdbserver(version 6.7.1) on X-server(say it remote machine) and gdb(version 7.7) on Ubuntu machine(local machine or the machine where X-server is running), but its not working.
This is what I tried so far:-
executed below commands on remote machine
MY_Application &
gdbserver localhost:8888 --attach process_id
executed below commands on local machine
gdb ./MY_Application
(gdb)target remote :8888
Now on local machine gdb is showing this message
Could not load shared library symbols for 20 libraries, e.g. /usr/lib/libqt.so.3.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
As far as understand it, gdb is not able to load the shared libraries and there are 20 of them. As a result of this I am not able to find the symbols present in these shared libraries.
I tried to load the symbols from library files on local machine using symbol-file command on gdb but that leads to address mismatch
So I used the below command
(gdb)set sysroot remote:/
but it is again showing an error message
Could not open 'remote:/usr/local/davis/lib/usr/lib/libqt.so.3' as an executable file: Function not implemented
Can anyone please tell me what am I doing wrong here? If there is an alternate solution to load the symbols from shared libraries please suggest.
P.S. Both the MY_Application binaries are same.
Finally i found a solution for my problem.
The problem was in step 2 shown above. Somehow gdb was not loading all the symbols and PATH to shared libraries. Although PATH shown with ldd command was accurate. But still it was not working for me if I simply run the gdb ./MY_Application
So I executed one more command after this i.e.
file MY_Application
and also copied library file from
/srv/chroot/loc/usr/local/davis/lib/ to /usr/local/davis/lib/ after this I connect it to remote server and now it is working fine.
For reasons beyond the scope of this question I have to statically link the libstdc++ to my executables. The practical downside is that now GDB can't step in to the stdlib symbols. When I was using the shared linked variants of my executable GDB had no issues to show me the accompanying source files (after I had installed the source package through apt-get under ubuntu which installed it under /build)
How can I step into libstdc++ functions when it is statically linked to an executable in GDB, under Ubuntu (14.04)?
Ubuntu package libstdc++6-4.8-dbg provides the static library with debug symbols at /usr/lib/x86_64-linux-gnu/debug/libstdc++.a; try building your executable against it and then run gdb.