problem with non-standar-location shared libraries

[neich]

Hi,

I have a project that uses some non-standard shared libraries. These are not in /etc/ld.so.conf and I don't want them to be (they are also in development, but outside C::B). When linking I use pkg-config to find them. And then, when I try to run the program from within C::B, then I get a "error while loading shared libraries".

So I understand that C::B assumes that all the shared libraries used during the linking process can be found using /etc/ld.so.conf, right ? If this is true, is there any way to modify LD_LIBRARY_PATH in a per-target execution basis ?

Thanks
Nacho

[gzahl]

Hi,
Im have a similar problem. The LD_LIBRARY_PATH variable isnt used. if i run my program from konsole it works fine. but under xterm and c::b i get a shared object not found error. How can set the LD_LIBRARY_PATH Varible? I saw some Threads about similar problem, but nothing helped up to now.
Thank you

Cheers
Manu

[Game_Ender]

CB doesn't assume anything, it just doesn't launch executables with its own environment so any customizing of the LD_LIBRARY_PATH you did will no longer be in effect.  There is an Environment Variable plugin which should fix this.

[MortenMacFly]

There is an Environment Variable plugin which should fix this.

Yes, but this doesn't work per-target. I question myself why do you (neich and gzahl) depend on LD_LIBRARY_PATH? In the end you can easily setup the compiler/linker path's yourself (per-target)...?! There should be no need to depend on that - especially if you think cross-platform.
With regards, Morten.

[neich]

Yes, but this doesn't work per-target. I question myself why do you (neich and gzahl) depend on LD_LIBRARY_PATH? In the end you can easily setup the compiler/linker path's yourself (per-target)...?! There should be no need to depend on that - especially if you think cross-platform.
With regards, Morten.

Maybe I am missing something here, but if you set up the library paths in the linker (-L option), these paths are ignored during execution, and only the ones in /etc/ld.so.conf and $LD_LIBRARY_PATH are used. So you have to take care yourself to include the paths on -L into LD_LIBRARY_PATH. And I think that it would be fairly easy that c::b automatically do this. It is just a matter of collectiong all the -L paths (per target) and insertthem into LD_LIBRARY_PATH during execution. Or at least set up an option to do this.

In my case, I am using some external libraries that have a debug and a release version, so when I execute the debug application inside c::b I want to load the debug version of the library, and when I execute the release version inside c::b I want to load the release version. I can get this setup in the linking stage, but not in the execution step, so I have to execute the application outside c::b, which is a pain. I have solved the problem using static libraries, but then linking takes a lot of time ...

Nacho

[gzahl]

In the end i solved the issues by using boost::build, but im a little sad, that its hard in c::b and kdevelop to link shared libraries right. Does C::B use a makefile? Can you compile C::B programs without C::B straightforward? Im new to C::B, so maybe im wrong, but it is not very clear how it does, what it does. Even if the menu structue a lot better than in kdevelop.

Now C::B calls an instance of bjam and this works for me.

Greetings
Manu

[Game_Ender]

I think this is a missing feature of Code::Blocks.  Given the main developers seem to use windows most of the time I can see why this hasn't been done.  Any reasonably large Unix program uses environment variables, and these might need to change based on certain circumstances.  There should just be a list of environment variables for each target that are set before running it.  LD_LIBRARY_PATH is just one example.

[afb]

It would be nice to clean this up, yes... Also need to add support for DYLD_LIBRARY_PATH which is the same thing (as LD_LIBRARY_PATH) but for the Darwin/Mac OS X platform.

Working on this along with a patch to permit using Terminal.app instead of xterm.