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.
Related
I am using Eclipse Eclipse 2022-09 with CDT 10.7.1202208222120 on Fedora 37.
I am working on a simple C++ testapplication (libTest.cpp) which should use code from 2 shared librarys (libBasexCpp and libBasexSocket).
All 3 sources compile without errors and building libTest also completes without error. In the Properties -> Settings -> Build Artifact dialog for libBasexCpp and libBasexSocket, I have chosen not to use a Output Prefix (prefix is ""). In the debug directorys, libBasexCpp.so and libBasexSocket.so are created.
When I try to run the testapplication as a local C/C++ application, I first have to choose which local application should be run , liblibTest or libTest.
Executing either one of the 2 results in a message, saying that liblibBasexCpp can not be found.
I have added Library Paths (DYLD_LIBRARY_PATH = ${workspace_loc:/libBasexCpp/Debug};${workspace_loc:/libBasexSocket/Debug} as Environmentvariable to the run configuration.
How can I configure Eclipse in such way that it loads the shared library's?
Basically, to configure the shared librarys and the test application, I followed the instructions as I found on Shared libraries with Eclipse CDT and cygwin on Windows.
What was missing therein was the instruction to add in the Run configuration the variable LD_LIBRARY_PATH containing the paths to both libraries.
After adding this variable, the test application worked.
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.
I have a simple program that displays an image using OpenCV 4.3. If I run it in terminal e.g. ./test_opencv it displays the image, however if I double-click the same executable in a Finder window, the read image is empty.
What is the cause of this?
I am including cmake 3.16, apple clang 11.0.3, and am including all opencv libraries.
The reason of it is working on terminal is that the program can reach the libraries which it needs. You should add the necessity libraries to environment by adding to .bashrc file.
Open terminal and find the all libraries which the program using by the command:
Ubuntu : ldd <path>
Mac: otool -L <path>
Then open bashrc and add the libraries which are not exist in there. Here is the link for bashrc on mac. Also you should search what is static library and dynamic library means.
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 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!