Shared objects on linux

[Halan]

Hey,

I am using Code::Blocks 8.02 with G++ on Ubuntu 8.10 and i have to say that when linking my executeable to a shared objects Code::Blocks will put the path from the project to the .so not from the executable/working directory to the .so and therefore it won't load the shared object.

Has this issue been resolved in one of the nightly builds?

greetings,
Halan

[MortenMacFly]

Has this issue been resolved in one of the nightly builds?

This is not an issue with C::B but most likely with you project setup. You can choose the path to run the application in the project settings. First try setting it to the path where the libraries are.

[Halan]

Has this issue been resolved in one of the nightly builds?

This is not an issue with C::B but most likely with you project setup. You can choose the path to run the application in the project settings. First try setting it to the path where the libraries are.

i don't really think so
I have the project output, working directory in shared object in ./bin

If i compile+execute the executeable searches for the .so in ./bin/bin what kinda sucks. Maybe it is a problem with G++ not code::blocks

[Halan]

I wanna bump this because i still have to struggle with it

At the moment i am using the absoulte path to overcome this problem but this only works until I start using it on other machines too.

[CuteAlien]

Here's some good documentation how shared libs work on linux: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

It's not like on windows that the application-path of the binary is automatically searched for shared libraries. If you want to do something similar you have to set a rpath on linking. In c::b you could set that in "Other linker options". I suppose the following should do something close to the way it works on windows:
-Wl,-rpath -Wl,.

But if you do that it's probably nicer to put the shared libs in some subfolder,  like:
-Wl,-rpath -Wl,./my_shared_libs

This has also some disadvantages as the rpath works relative to your working-directory and not to your application-directory. Usually that's fixed by adding a startupscript which must be called instead of the binary which makes sure to set the working-directory (checkout googleearth, they have a nice script which will do that and I think it's GPL so you can copy it).

This works for developing. For releasing it to others it would also work, but many prefer to set LD_LIBRARY_PATH instead in the shellscript which is used to start the binary. I don't know why, probably because that way users can change that easily.

I'm not sure if there is a way to avoid rpath and instead set LD_LIBRARY_PATH before application start within C::B. If anyone knows how to do that an example would be nice.

[Halan]

strange but then it shouldn't search in workingDirectory/bin/Debug or so for shared libraries but in /usr/lib or similir, shouldn't it?

If i use LD_LIBRARY_PATH i have to dynamically load the libs right?

[CuteAlien]

Read through the link I've posted. It is explaining all that way better than I could. And the dynamic linking is automatic, when the .so is found you don't have to do much beside linking to the library. You don't have to do the loading yourself (unless you are writing a plugin system).