Hello all, not sure if this is the right section to post into, but since most of programmers have to distribute an application after development, I'm guessing one will be able to answer me

My problem is simple, when new .so are installed on a computer, they need to get registered with ldconfig, and you must tell the OS the path of your lib in some file, which differs from a distribution to another ( on my uBuntu 6.10, the file is /etc/ld.so.conf )

With dynamic runtime linking, theres no such problem, because the file can be in the same folder and will get linked flawlessly.

What is the best approach, for an installation process that :

A) Wouldn't require root password ( like for ldconfig )
B) Makes sure your app will find the .so it needs
C) Works on most distros

My app shall not require a compilation on the target system, everything is in binary.

Thank you for any lights on this.

I know a way to do this, but it's not really that simple. Installing the library in a system directory will by nature require root password. However, you can compile your program to link against a local object rather than one in the default library path. I put together a simple example that builds a program and its library and dynamically links them, all in the same folder:

http://www.funsitelots.com/c/local_library.tar.bz2

Just extract the tarball, enter local_library, run ./build to build the program, and run ./runapp to run the program. For some reason, you have to do `export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH` before you can run the app, that's why I made the ./runapp script, too.

Anyone know a simpler way to do this?

hey thank you for your reply

My guess is that, the important line is this one :

with -L. specifying the working directory as the lib search path, probably why you have to export the LD_PATH

the approach is interesting, I'm gonna test some things with this.

Thanks a lot

You can LD_LIBRARY_PATH no matter what the line used with gcc. That just tells gcc where to look for the library at compile-time. The actual location at run-time can be anywhere. By using a shell-based wrapper, you can set that up at run time along with any other environmental variables needed.
Here's an example I use to run gcc-2.95.3.
In your case, the exec line should be:
exec /path/to/your/program
or:
exec program
if the program is in the PATH set above. You can also use relatives paths if needed:
${PWD}/../../bin

everything seems to work great now.

Thanks for your reply gnashley, this was my next question :

How can I make my shell-based wrapper accessible from anywhere

so that, from any folder on the system, i can type : myApp and it would start, in the proper folder where it was installed. ( Installers are the target of my next questions )

And on a side note, what does '${PWD} does on that line : '${PWD}/../../bin'

The shell env var $PWD is 'Print Working Dir' ie rtn the current dir you are in.

Isn't that Present Working Directory? Anyway, it means the directory where the current process was executed from.
No there is no way to have your program available from anywhere on your system.
When you try to execute a program, the shell searches your PATH for a an executable program of the name you typed in. For ordinary users this is usually includes /usr/local/bin, /usr/bin and /usr/X11R6/bin. Only by installing your program under one of those directories can your user execute the program by simply typing the name of it.
Still, you can place it anywhere and run it by invoking the full path to it, or by cd'ing into the directory where it is and running ./prog-name

Try man pwd, although that's actually the cmd, rather than an env variable.