[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