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
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
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.
Quote from: Game_Ender on November 18, 2006, 11:57:14 PM
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.
Quote from: MortenMacFly on November 19, 2006, 09:38:14 AM
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
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
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.
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.