Re: Setting the search path environment variable for shared libraries

On Monday June 29 2020 00:55:42 Steve the Fiddle wrote:

>I'd prefer to avoid modifying CMakeLists.txt because it's under version
>control (and I'm not yet familiar enough with cmake)

No need for that! You just invoke cmake with `-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_INSTALL_RPATH=list`
where "list" is a semicolon-separated list of library install locations where you want ld.so to look for runtime libraries when the application starts. NB, you can also use this just for a shared library.


>I was guessing that I need to set it in:
>"Settings > Configure kdevelop > Environment"
>with:
>Variable: LD_LIBRARY_PATH
>Value: /opt/wxWidgets/lib/
>
>and then select that Environment Profile in:
>"Run > Configure Launches"
>
>but that doesn't work.

Yes, I'd expect that should work too.

>
>Unfortunately that does not work if I launch Audacity from a shell script
>(the only way so far that I can get it to launch from within kdevelop).

I don't see why it wouldn't, but then why launch from within KDevelop (other than via its built-in terminal emulator)?

>Audacity should launch. Am I misunderstanding the "environment profile"
>feature in kdevelop?

I don't know :) Those profiles are set before invoking external commands, so that the variables in question are set in the child process. Do they work for you in builds and/or when invoking CMake?

FWIW, I use KDevelop as little as possible as a full IDE and as much as possible as an editor with "intellisense" and VCS features. It's tricky to get around automatic invocation of cmake (but I've been finding a way). I guess I'm a control freak and I find that letting the application do more makes it compete for resources with what is being done (I also use out-of-tree build dirs OR add the in-tree build dir to KDevelop's exclusion list so it doesn't waste cycles trying to reload that directory continuously during builds).
Much as I appreciated graphical debuggers I also avoid to use those these days; with the average C++ application the debugger alone already requires so much RAM that I don't want another RAM hungry application competing for my measly 16Gb... Graphical debuggers are great in C and similar applications where they can help a lot exploring data structs. Doing that in the average modern C++ application is often a lot faster by recompiling with a few clever printfs at the right places (and here cmake's "install/fast" Makefile target is worth gold, executed in the appropriate build subdir).

All that is not really a rant, just a reality check and a NB that I don't have any actual recent experience with the features we're discussing (I typically don't even load the debugging plugins).

R.