-
Notifications
You must be signed in to change notification settings - Fork 0
Undefined reference to dlopen while using libtool
Documenting this because we ran into this problem at least twice now XD
You are using a Debian Linux or Debian-derived Linux distribution (such as Ubuntu) and you get this fun error during the final linking stages:
/bin/bash ../libtool --silent --tag=CC --mode=link gcc -std=c99 -Wall -Wextra -pedantic -g -O2 -o foxbot main.o ../src/libfoxbot.la ../src/libfoxbotaux.la
../src/.libs/libfoxbot.so: undefined reference to `dlopen'
../src/.libs/libfoxbot.so: undefined reference to `dlclose'
../src/.libs/libfoxbot.so: undefined reference to `dlerror'
../src/.libs/libfoxbot.so: undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
dlopen
on most Linux systems comes from the libdl
library (which is linked via the -ldl
flag).
libltdl
, part of libtool, always links to libdl
, so by extension one would expect that linking to libltdl
should automatically grant you access to dlopen
. This is indeed true if you use the vanilla libtool
to link your programs.
Debian does not like this default behavior, unfortunately. It requires you to explicitly link to libdl
if you are actually using symbols from libdl
, even if you already have an indirect dependency. The rationale being that if your program only has an indirect dependency on libdl
, it shouldn't be necessary to recompile your program if libdl
changes.
To respect Debian's decision on linking explicitly, one should link to libdl
explicitly. There are hacks to work around this by undoing Debian's tweak on libtool, but I don't think that's a good idea.
However, the better solution is to not use libdl
at all. Since libdl
is a low-level library and libltdl
is meant to be a portable higher-level interface to it, it kind of defeats the purpose if you actually call functions from libdl
directly. So really, the right solution is to use the portable interface provided by libltdl
as documented.