2

I author a shared library that 'dlopens' another shared library (of which I am not the author/owner)

My shared library, is 'dlopened' by an executable (of which I am not the author/owner)

So the hierarchy is: exe dlopen's my library, my library dlopen's another library.

The library that my library dlopens utilizes openssl. However, it would seem that the authors of this library do not link the openssl libraries - perhaps assuming that the user of the library will.

Thus, when I attempt to dlopen their library, I am met with undefined symbol errors.

Even if I link the openssl libraries into my library, I still get the undefined symbol errors.

My questions are two:

1) When the library requiring openssl is dlopen'ed, does it only know to 'look' towards the exe to do the symbol resolution?

2) Are there special linker flags that I might be missing on my library, linking in openssl, that I need?

thanks.

Mark Setchell
  • 191,897
  • 31
  • 273
  • 432
user3472
  • 173
  • 9
  • Perhaps the system just can't find the `SSL` libraries, are they in a standard location? You could try setting `LD_LIBRARY_PATH` to the `SSL` libs. – Galik Jul 20 '16 at 12:12

2 Answers2

1

Most probably the library that depends on OpenSSL does so in a dynamic way. You can use the ldd command on the library .so to confirm this. If you cannot spot a dependency to OpenSSL there, it might mean that the library manually loads OpenSSL (by itself calling dlopen manually), in which case you cannot do much - contact the library maintainers for a fix.

If the dependency does show up as part of the ldd output, it means that the operating system is responsible for loading it. The rules for this are lengthy and complicated, but the most important things you need to know about are LD_LIBRARY_PATH and rpath.

The former allows the user to specify a system-wide list of directories where the loader will looks for .so files to load. The latter is a list of paths that is built into the library itself that will be considered by the loader.

Usually it is expected of a library maintainer to set their rpath up such that the library will load correctly if all dependencies are installed correctly. After all, relying on the user to set their LD_LIBRARY_PATH in a certain way is not very convenient. Here's how you can inspect the .sos rpath.

So you need to ensure a couple of things: Whether OpenSSL is installed on the machine, if it's the correct version and if it's in a location that can will be searched by the loader. This can be a bit tedious and it might not be obvious in the end who's fault it is that the stuff does not load, but hopefully this will be enough info to help you find a solution.

Community
  • 1
  • 1
ComicSansMS
  • 51,484
  • 14
  • 155
  • 166
0

The problem really is with the shared library that has undefined symbols. This can be made to work, but is unportable, and may break when changing linkers (e.g. gold vs. plain ld).

If they need the symbol, they need to link to openssl. If they want to be independent of the library (maybe dynamically switching across ABI-compatible openssl forks - just a wild guess, mind you) they should themselves access the openssl implementation through dlopen and manually resolve the symbols through dlsym. Assuming that the dynamic linker will magically "propagate" the symbols.

Now, there might be a way to make this work.

The "availability" of symbols from the dlopen'ed library is controlled when you dlopen, among others through the RTLD_LOCAL / RTLD_GLOBAL flags.

Ergo, you could try to dlopen openssl with RTLD_GLOBAL before you dlopen the library that requires openssl.

sylvain.joyeux
  • 1,659
  • 11
  • 14
  • Thanks for the feedback. Yes - If I dlopen the openssl libraries before dlopen'ing the library that requires it, everything works fine. I was wondering if there was a way to avoid doing that as it seems like there ought to be. Thanks. – user3472 Jul 20 '16 at 12:30
  • 1
    There is a way: not intentionally breaking the dynamic linking process the way the library you depend on does. – sylvain.joyeux Jul 20 '16 at 12:54