Scenario
Dev machine running Ubuntu 20.04 and QtCreator. Qt libs are installed to /home/mark/Qt/6.2.0/gcc_64/lib.
Target machine running Ubuntu 20.04. Qt libs are installed to /home/user/Qt/6.2.0/gcc_64/lib.
Issue
When debugging a remote application from QtCreator I get:
Could not load shared library symbols for 8 libraries, e.g. /home/user/Qt/6.2.0/gcc_64/lib/libQt6Gui.so.6.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Setup
In Tools > Options > Debugger > GDB > Additional Startup Commands I wrote:
set sysroot /home/user/Qt/6.2.0/gcc_64/
set solib-search-path /home/user/Qt/6.2.0/gcc_64/
Questions
I read somewhere that to speed up the debugging I need to set sysroot to the local libraries (i.e. /home/mark/... instead of /home/user/...). Which is the correct path?
Is it correct to set sysroot to the parent directory of the lib folder that contains the Qt libraries?
where should I run the info sharedlibrary command?
Which is the correct path?
The one where libraries can be found during debugging, i.e. the path on the development machine.
Is it correct to set sysroot
The sysroot should be used when you have a complete set of target libraries (including all system ones).
That is, if you had the complete mirror of target libraries under e.g. /home/mark/target/, then you would use set sysroot /home/mark/target.
Since you don't have such a directory, you should not use sysroot at all.
Instead, you should tell GDB that it can find libraries in /home/mark/Qt/6.2.0/gcc_64/lib with set solib-search-path /home/mark/Qt/6.2.0/gcc_64/lib.
where should I run the info sharedlibrary command?
At the (gdb) prompt.
Related
I have a docker image which I am using to build a project. That project generates several executables and .so libraries.
I am able to GDB debug on the command line with the proper LD_LIBRARY_PATH set, and it finds the libraries correctly and I am able to step debug into those .so files.
I am trying to use QtCreator "Start and debug external application" to gdb debug this application.
In QtCreator, I am using the set solib-search-path command in the "Additional Startup Commands" of the Debugger->GDB tab , and in the QtCreator debug log I see it being set:
set solib-search-path /home/me/mypath/dist.x86/Linux5.4_x86_64_cc_glibc_PTH_64_DBG.OBJ/lib:/lib/x86_64-linux-gnu:/lib64
However, when the program runs, the executable is not finding the correct version of the shared library.
Is there something else I need to do to make this work? Do I need to launch QtCreator from an environment where LD_LIBRARY_PATH has already been set? I have verified with ldd the executables and shared libraries have the path I am using for solib-search-path once I have set LD_LIBRARY_PATH when I am using command line GDB to debug.
I am confused by the commands set solib-search-path and set sysroot, not sure when to use one or another. In my case symbols are only loaded when i used both the commands. Is it always both the commands are required and what does each command does.
For here http://visualgdb.com/gdbreference/commands/, it looks like sysroot looks in subdirectories too, then why is solib-search-path required, if both search for libraries and load symbols from those libraries
gdb searches first for libraries in sysroot (with an absolute path), and then only if it fails to find them it searches into solib-search-path (with a relative path).
For that reason, when using gdb server / remote debugging you probably want to use ONLY gdb's sysroot option. On a Linux system using solib-search-path will NOT work unless you change the value of sysroot, because the default value of sysroot is target, meaning that gdb is loading the so-file found on the filesystem you are debugging. This is also what is indicated in gdb's documentation:
set solib-search-path path
colon-separated list of directories to search for shared libraries.
‘solib-search-path’ is used after ‘sysroot’ fails to locate the
library, or if the path to the library is relative instead of
absolute. If you want to use ‘solib-search-path’ instead of ‘sysroot’,
be sure to set ‘sysroot’ to a nonexistent directory to prevent GDB
from finding your host’s libraries. ‘sysroot’ is preferred; setting it
to a nonexistent directory may interfere with automatic loading of
shared library symbols.
As indicated in this thread, the use-case for solib-search-path is rather:
solib-search-path is there mostly to help targets like Windows that
don't report to the debugger the full path to the shared library.
GNU/Linux always works with full patchs, such as
"/usr/lib/libjpeg.so.8"
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.
I am using Qt 5.2.1 (from QtCreator 3.0.x) on Ubuntu Linux (12.04 LTS) and I am trying to customize the build process... My aim is to have a build directory different from the source directory (additionally I would like to specify also different directories from temporary files)...
So at the end of the story, I want to have a build directory with the executable and all the shared libraries (so I set the executable rpath to include its own directory) and I want to debug my application from that folder...
Here is my .pro file:
# Configure target directory
DESTDIR = $$PWD/build/bin
# Configure working (obj) directory
OBJECTS_DIR=$$PWD/build/obj
# Configure working (moc) directory
MOC_DIR=$$PWD/build/moc
# Let the linker to search for libraries in build path
# and set the executable search path for including its own folder
DOLLAR = $
QMAKE_LFLAGS += -L $$DESTDIR -Wl,-rpath,$${DOLLAR}$${DOLLAR}ORIGIN
Everything is fine: the compilation is performed exactly as I want... but I've a trouble with QtCreator debugger (GDB) at this stage...
When I try to start the debugging, QtCreator says:
Could not load shared library symbols for libRtCore.so.1. Do you need
"set solib-search-path" or "set sysroot"?
(please consider that libRtCore.so.1 is a shared library which my executable relies on and it is available, of course, in the build directory)... How can I setup the debugger for loading symbols also for libRtCore.so.1? Any ideas?
Ok, found... the problem was that I was running the application using "Run in terminal"... Clearing the corresponding checkbox (as in the screenshot here below) the debugger works like a charm!