The linux runtime linker, ld.so searches in the following locations for an .so file:

* Using the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.

* Using the environment variable LD_LIBRARY_PATH . Except if the executable is a setuid/setgid binary, in which case it is ignored.

* Using the DT_RUNPATH dynamic section attribute of the binary if present.

* From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. If, however, the binary was linked with -z nodeflib linker option, libraries in the default library paths are skipped.

* In the default path /lib, and then /usr/lib. If the binary was linked with -z nodeflib linker option, this step is skipped.

I believe, by default when building an executable, the gcc toolchain will place . on the DT_RPATH section attribute, but I'm not positive about that.

Quote:Original post by Lode
Do .so files in Linux work the same way as .dll files in Windows? I mean, if I'd make my own .so file, and let a program use it, will it work if I put the .so file in the same folder as the executable of the program and will it find it?

Make a bash script which sets LD_LIBRARY_PATH to the current directory and then runs the executable.

Note that . is the current working directory *NOT* the directory the binary came from.

Also, I believe that . is not normally searched for libraries (that would be a significant security risk, I mean, if root starts running commands when in users home directories).

Windows does not seem to care that you might be running commands with a CWD of a less privileged user - in fact, . is permanently in its path anyway.

Mark