Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: cacb on November 25, 2021, 02:52:45 pm
-
Inspired by the discussion in the thread Export to CMake (https://forums.codeblocks.org/index.php/topic,24714.msg168622/topicseen.html#msg168622) I downloaded and built the gede debugger (and kdbg as well). This is under Kubuntu 20.04. I was able to start these debuggers from a simple user defined tool entry in the Code::Blocks Tools menu. Debugging worked for simple programs with no external *.so files so that was kind of promising.
Then I tried slightly larger GUI programs depending on *.so files and both debuggers (gede and kdbg) refused to launch these because the *.so files could not be found. Then I tried launching the the exact same commands from a terminal window (konsole) and then debugging worked fine, *.so fiiles were found.
The difference is that my user's LD_LIBRARY_PATH (defined in ~/.bashrc ) is cleared when launching Tools menu items. This is unexpected (and different from similar features in Windows). When you launch the built-in debugger in C::B I can see LD_LIBRARY_PATH is explicitly set, but it doesn't seem logical that the Tools menu would interfere with it?
Any comments?
-
Tools or Tools+ plugin?
-
Tools menu, I have disabled Tools+ long ago and I do not use it
-
I solved the problem with loading *.so files.
Using ~/.bashrc to define LD_LIBRARY_PATH only works in a bash shell, so it is not the proper way to do it for all uses.
Instead, I made a file /etc/ld.so.conf.d/myconfig.conf
and put a line in there defining the directory of my *.so files.
Then I did a
Now things worked as intended, the debuggers could find my *.so files
-
So the big question is, is this expected behaviour from codeblocks or not? I mean, isn't codeblocks adding its own paths to LD_LIBRARY_PATH, and when we use them in the Tools menu start, could this interfere?
-
So the big question is, is this expected behaviour from codeblocks or not? I mean, isn't codeblocks adding its own paths to LD_LIBRARY_PATH, and when we use them in the Tools menu start, could this interfere?
When you start the built-in debugger in C::B, then C::B will modify the LD_LIBRARY_PATH setting for that debug run as reported in the C::B console, it includes the project's linker search directories I believe. That's a reasonable behavior for the debugger plug-in.
A different question is what happens when you run something from the Tools menu. It seems to me now that LD_LIBRARY_PATH is undefined in that context because neither codeblocks (the parent process) nor the Tools menu item is running in the context of a bash shell, so ~/.bashrc isn't involved. Because I had defined LD_LIBRARY_PATH there, it wasn't applied when I tried external debuggers. When i repeated the same command from a terminal window it worked because it was started from a bash shell.
So my guess is that codeblocks does not actively erase the LD_LIBRARY_PATH setting when running Tools menu items, it just doesn't apply any bash settings. That means the behavior should have been expected.
Placing the *.so search path in /etc/ld.so.conf.d/myconfig.conf makes loading shared libraries independent of bash, so then it works in both cases. It is quite logical, the only thing is that the path /etc/ld.so.conf.d/ is quite odd :-)
At least this is my understanding, I am happy to be corrected if some of this is inaccurate.