Author Topic: Tools menu and Linux environment  (Read 778 times)

Offline cacb

  • Lives here!
  • ****
  • Posts: 504
Tools menu and Linux environment
« on: November 25, 2021, 02:52:45 pm »
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?
 

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3020
Re: Tools menu and Linux environment
« Reply #1 on: November 25, 2021, 10:48:55 pm »
Tools or Tools+ plugin?

Offline cacb

  • Lives here!
  • ****
  • Posts: 504
Re: Tools menu and Linux environment
« Reply #2 on: November 26, 2021, 06:59:01 am »
Tools menu,  I have disabled Tools+ long ago and I do not use it

Offline cacb

  • Lives here!
  • ****
  • Posts: 504
Re: Tools menu and Linux environment
« Reply #3 on: November 26, 2021, 08:22:46 pm »
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

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3020
Re: Tools menu and Linux environment
« Reply #4 on: November 27, 2021, 11:39:12 pm »
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?

Offline cacb

  • Lives here!
  • ****
  • Posts: 504
Re: Tools menu and Linux environment
« Reply #5 on: November 28, 2021, 10:25:03 am »
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.