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?

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