Tools menu and Linux environment

[cacb]

Inspired by the discussion in the thread Export to CMake 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?
 

[BlueHazzard]

Tools or Tools+ plugin?

[cacb]

Tools menu,  I have disabled Tools+ long ago and I do not use it

[cacb]

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

Code

sudo ldconfig

Now things worked as intended, the debuggers could find my *.so files

[BlueHazzard]

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?

[cacb]

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.