# Library locations, Windows and Linux?

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

## Recommended Posts

Right, I have this little problem that I need to solve regarding DLL and SO locations and the ways for the main application to find them. The current situation is this: I have a Mozilla browser plugin (my main app) that sits in Program Files\Mozilla Firefox\Plugins or ~/.mozilla/plugins. In addition to that I have several other DLLs/SOs that are required by the plugin to operate. Now, the easiest solution would of course to A) stick them into Windows\System32 or for example /usr/local/lib in Linux or B) stick them into the Mozilla plugins folder. However, both are kinda "ugly" solutions - it is very likely that no other application uses those libraries which makes option A not a good one. Also if some other application did the same and for some reason installed an incompatible version of the libraries overwriting the compatible ones, things would get messy. B is just plain ugly for the reason that the libraries aren't directly Mozilla plugins themselves but only there to be used by one. Now a better solution in my opinion would be to install them into a subdirectory under Mozilla plugins folder but then I face the problem: How do I tell my plugin where to find them? I know that in the Windows world we have SetDllDirectory() -function that could be used for that purpose, but what about Linux? The idea is also to get this thing ported to Mac so that should be taken into consideration as well. Another way could be to add the library directory to the path environment variables but once again it's problematic. Can work for Windows but not so well for other platforms. Also the idea is to make the plugin installation an easy task not requiring anything extra from the end user and should work in situations where the user doesn't have admin/root permissions. Any suggestions how to do this? Right now the only viable, easy option would be to shove them all into the browser plugin directory but I'd rather find a better solution.

##### Share on other sites
On Unix (Linux, Mac OS X) runtime link loading is done by the runtime link loader. There are no system calls you can make to the OS to affect how that program behaves.

You can, however, affect its behaviour by presetting certain environment variables (eg. LD_LIBRARY_PATH for ld.so on Linux, there's something similar for the Mach-O loader but the name escapes me at the moment). Unfortunately, that would require setting the environment variable before your plugin is loaded.

Another thing you can do is hardcode the location of the external shared objects (.so on Linux, .dylib on Mac OS X) into your plugin sp the runtime link loader will know where to look. On OS X you can also make the .dylib a part of your plugin bundle.

Finally, on all three platforms you could have your plugin be a thin wrapper around your real plugin and use dlopen/opendl/LoadLibrary, which would allow you to control the search path.

##### Share on other sites
Quote:
 Original post by BregmaYou can, however, affect its behaviour by presetting certain environment variables (eg. LD_LIBRARY_PATH for ld.so on Linux, there's something similar for the Mach-O loader but the name escapes me at the moment).

It is DYLD_LIBRARY_PATH.

EDIT:

Without being an expert in these things, I can tell something about the experiences I had with linking against libraries not located in the standard locations:

The dynamic loader in linux uses the *.la descriptor if present. That file defines the proper location of the library and whether or not it is installed. I have had some trouble after linking with a library that wasn't installed at the pre-defined location (i.e. those mentioned in the la file); the library was linked but it wasn't found at runtime although its path was correctly added to the $LD_LIBRARY_PATH. Under Mac OS X the path of a library is written to the binaries when linking. AFAIK one step of installing means to do a correction of such pathes if necessary. You may have a look at the command line tool /usr/bin/install_name_tool (at least in Tiger) if you're using makefiles. E.g. I do steps like /usr/bin/install_name_tool -change ../${SYSTEM}/lib/libCore.dylib @executable_path/../Resources/libCore.dylib ARTY
to change the binary's (==ARTY) path of a library (==libCore.dylib), where linking was done against an instance in ../${SYSTEM}/lib/, but should be loaded at runtime from @executable_path/../Resources/ (notice please that @executable_path is a kind of variable known to the dynamic loader, while${SYSTEM} is a variable of the makefile). Perhaps there are more convenient ways; as said, I'm no expert in these issues.

AFAIK using absolute pathes will force the loaders under linux or Mac OS X to not use presetted pathes, but of course absolute pathes have their own drawbacks.

[Edited by - haegarr on November 2, 2007 1:48:48 PM]

1. 1
2. 2
3. 3
4. 4
Rutin
16
5. 5

• 12
• 9
• 12
• 37
• 12
• ### Forum Statistics

• Total Topics
631415
• Total Posts
2999965
×