Jump to content
  • Advertisement
Sign in to follow this  
Lode

.so files

This topic is 4841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!