[getdns-users] why do we link libgetdns.so to dlopen?

Robert Edmonds edmonds at debian.org
Thu Nov 5 00:35:22 CET 2015


W.C.A. Wijngaards wrote:
> Hi Daniel,
> 
> On 11/04/2015 11:23 PM, Daniel Kahn Gillmor wrote:
> > i noticed that libgetdns.so is being linked against libdl, but i
> > don't think we're using dlopen or any of the other functions
> > exported from ldl.
> > 
> > fwict, ./configure is adding -ldl because of m4/acx_openssl.m4,
> > which claims:
> > 
> > # openssl engine functionality needs dlopen(). BAKLIBS="$LIBS" 
> > AC_SEARCH_LIBS([dlopen], [dl]) if test "$LIBS" != "$BAKLIBS"; then 
> > LIBSSL_LIBS="$LIBSSL_LIBS -ldl" fi
> > 
> > However, we're not using OpenSSL Engine support directly.  If some 
> > library user wants to initialize openssl's engine support, they
> > should be able to do that with OpenSSL itself, and then they should
> > be able to get libcrypto and/or libssl to use libdl directly.
> 
> But that is not how the linker works, I understand you would like it to.

On the systems that I'm familiar with (GNU/Linux, FreeBSD), that is how
the runtime linker does work.  Libraries needed indirectly are located
recursively.  In fact the GNU 'ldd' utility has an option ('-u') to
print "unused direct dependencies".

But I don't believe this kind of behavior is regulated by the relevant
standards (POSIX, C?).

> > On some minimal systems, libcrypto and libssl might be built
> > without engine support at all; in that case, libgetdns is adding a
> > superfluous dependency to the linker.
> 
> Regardless of what calls getdns uses, the dependency of openssl on
> libdl has to be satisfied for the linker to succeed.

For shared libraries, the linker reads the ELF sections of libssl.so and
finds that it depends on libdl :-)

Static libraries don't have a similar way to pass transitive
dependencies, so they end up needing the dependencies spelled out
explicitly when linking statically.  If you use the pkg-config system (I
don't believe getdns does, though), you can have pkg-config generate the
minimal set of libraries needed dynamically when invoked with
"pkg-config --libs", and the complete set of libraries needed statically
when invoked with "pkg-config --libs --static".  But not everyone uses
pkg-config, of course.

> No, you cannot safely apply that patch.  The library will not link
> properly (at compile time or at run time, not sure) for some
> setups/platforms.  Leaving out -ldl when possible would be a nice
> patch (that I would also like for unbound and NSD).

Do you know of any specific setups/platforms that would actually fail
(when linking dynamically) if the full set of direct library
dependencies + transitive library dependencies are not spelled out at
compile/link time?  Just curious.

(Perhaps Windows?  Does Windows even have dlopen?)

-- 
Robert Edmonds
edmonds at debian.org


More information about the Users mailing list