我可以强制动态库链接到特定的动态库依赖项吗？

Question

I'm building an dynamic library, libfoo.so , which depends on libcrypto.so .

Within my autotools Makefile.am file, I have a line like this:

libfoo_la_LIBADD += -L${OPENSSL_DIR}/lib -lcrypto

where $OPENSSL_DIR defaults to /usr but can be overridden by passing --with-openssl-dir=/whatever .

How can I ensure that an executable using libfoo.so uses ${OPENSSL_DIR}/lib/libcrypto.so (only) without the person building or running the executable having to use rpath or fiddle with LD_LIBRARY_PATH ?

As things stand, I can build libfoo and pass --with-openssl-dir=/usr/local/openssl-special and it builds fine. But when I run ldd libfoo.so , it just points to the libcrypto.so in /usr/lib .

The only solution I can think of is statically linking libcrypto.a into libfoo.so . Is there any other approach possible?

Answer 1

Details of runtime dynamic linking vary from platform to platform. The Autotools can insulate you from that to an extent, but if you care about the details, which apparently you do, then it probably is not adequate to allow the Autotools to choose for you.

With that said, however, you seem to be ruling out just about all possibilities:

• The most reliable way to ensure that at runtime you get the specific implementation you linked against at build time is to link statically. But you say you don't want that.

• If you instead use dynamic libraries then you rely on the dynamic linker to associate a library implementation with your executable at run time. In that case, there are two general choices for how you can direct the DL to a specific library implementation:

  1. Via information stored in the program / library binary . You are using terminology that suggests an ELF-based system, and for ELF shared objects, it is the RPATH and / or RUNPATH that convey information about where to look for required libraries. There is no path information associated with individual library requirements; they are identified by SONAME only. But you say you don't want to use RPATH ^* , and so I suppose not RUNPATH either.

  2. Via static or dynamic configuration of the dynamic linker . This is where LD_LIBRARY_PATH comes in, but you say you don't want to use that. The dynamic linker typically also has a configuration file or files, such as /etc/ld.so.conf . There you can specify library directories to search, and, with a bit of care, the order to search them.

Possibly, then, you can cause your desired library implementation to be linked to your application by updating the dynamic linker's configuration files to cause it to search the wanted path first. This will affect the whole system, however, and it's brittle.

Alternatively, depending on details of the nature of the dependency, you could give your wanted version of libcrypto a distinct SONAME. Effectively, that would make it a different object ( eg libdjcrypto) as far as the static and dynamic linkers are concerned. But that is risky, because if your library has both direct and indirect dependencies on libcrypto, or if a program using your library depends on libcrypto via another path, then you'll end up at run time (dynamically) linking both libraries, and possibly even using functions from both, depending on the origin of each call.

Note well that the above issue should be a concern for you if you link your library statically, too. If that leaves any indirect dynamic dependencies on libcrypto in your library, or any dynamic dependencies from other sources in programs using your library, then you will end up with multiple versions of libcrypto in use at the same time.

Bottom line

For an executable , the best options are either (1) all-static linkage or (2) (for ELF) RPATH / LD_LIBRARY_PATH / RUNPATH , ensuring that all components require the target library via the same SONAME . I tend to like providing a wrapper script that sets LD_LIBRARY_PATH , so that that its effect is narrowly scoped.

For a reusable library , "don't do that" is probably the best alternative. The high potential for ending up with programs simultaneously using two different versions of the other library (libcrypto in your case) makes all available options unattractive. Unless, of course, you're ok with multiple library versions being used by the same program, in which case static linkage and RPATH / RUNPATH (but not LD_LIBRARY_PATH ) are your best available alternatives.

---

^* Note that at least some versions of libtool have a habit of adding RPATH entries whether you ask for them or not -- something to watch out for. You may need to patch the libtool scripts installed in your project to avoid that.