22

I'm working on a Firefox plugin that uses external libraries to render 3D graphics on the browser.

The problem is that I want the plugin to use external libraries packed with it without changing the LD_LIBRARY_PATH variable.
The libraries are installed in a position relative to the plugin (a shared library too), while the actual executable (i.e. the browser) can be located somewhere entirely else.

I'm testing it on Ubuntu (no problem at Windows version of the plugin) My dependencies are OpenSceneGraph libraries and static compilation will make the plugin really big (not an option if there is another one).

NoDataDumpNoContribution
  • 10,591
  • 9
  • 64
  • 104
leosamu
  • 221
  • 1
  • 2
  • 3
  • 2
    This could be useful: http://stackoverflow.com/questions/3015411/shipping-gnu-linux-firefox-plugin-with-shared-libraries-for-installation-with-no – Dmitry Yudakov Oct 19 '10 at 07:23
  • Interesting, i can confirm that with a simple test program. It uses `dlopen()` to load a `lib1` and `lib1` links to a `lib2` and uses `$ORIGIN` to load it from a relative path. This works without problems. – Georg Fritzsche Oct 19 '10 at 22:56

3 Answers3

28

Use the rpath option when linking and specify the 'special' path $ORIGIN.

Example:

-Wl,-R,'$ORIGIN/../lib'

Here's a site that elaborates on using $ORIGIN: http://www.itee.uq.edu.au/~daniel/using_origin/

lothar
  • 19,853
  • 5
  • 45
  • 59
  • 5
    the link is broken (5 years old yes I know :) ) – dashesy Sep 02 '15 at 20:02
  • [Wayback Machine](https://web.archive.org/web/20130915172134/http://itee.uq.edu.au/~daniel/using_origin/) to the rescue :) – maddouri Dec 13 '15 at 02:44
  • Also, [it seems](https://en.wikipedia.org/wiki/Rpath) that [`chrpath`](http://man.devl.cz/man/1/chrpath) and [`patchelf`](http://man.devl.cz/man/1/patchelf) can help too (I haven't tried them yet though...) – maddouri Dec 13 '15 at 02:53
  • Be careful when using `$ORIGIN` as it might be redefined somewhere else in the Makefile. In my case it was somehow set to a completely unrelated value. – Zenul_Abidin Mar 28 '22 at 05:24
0

You could maybe use the -L flag during the compilation to specify the relative path where the linker can find your shared objects.

If you have already generated your lib, you can link by directly invoking the ldcommand.

Tips : You can easily check if some symbols are defined in a lib using the unix command nm. This is a useful way to check that the linking is well-done.

(If I were you, I would just change temporaly the LD_LIBRARY_PATH as you said in your post. Why don't you want to do this ?)

ThR37
  • 3,965
  • 6
  • 35
  • 42
  • It is not about the linker finding the libraries, it's about the loader finding them in a location relative to the library currently being loaded (the plugin). With plugins you can't control how the host process (i.e. the browser) is invoked, thus enviroment variables won't do it. On OS X `@loader_path` does the trick, on Linux i don't know. – Georg Fritzsche Oct 18 '10 at 16:16
  • Ok sorry for the bad reading. Maybe the best thing to do is using language specific commands to load the lib at runtime. I will probably delete this answer tomorrow if I don't find a way to solve this properly. – ThR37 Oct 18 '10 at 16:35
  • The usual dynamic loading has the major disadvantage of not having the stubs, so you have to resolve the symbols manually :/ – Georg Fritzsche Oct 18 '10 at 16:50
-3

It's wrong to use relative rpath for security reason,

You should use libdl functions (dlopen, etc)

drizzt
  • 737
  • 1
  • 7
  • 14
  • 4
    If implemented poorly, usage of rpath can certainly cause problems, but Linux (and other systems) have built-in safeguards. For example, under certain circumstances, ld.so will not expand ORIGIN at all. Additionally, relative paths are absolutely necessary for relocatable programs; otherwise, you end up having to install a software package to a fixed location -- eg, being forced to install matlab to /usr/share/matlab always instead of something like /opt/matlab, or /usr/local/matlab, etc. – Brian Vandenberg Jul 03 '12 at 16:09
  • 2
    Furthermore, people can make informed decisions about whether to use ORIGIN expansion, particularly if the software in question is of their own creation and being used on their own hardware. – Brian Vandenberg Jul 03 '12 at 16:10