-
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.