Hi Marc, On 2021-04-28 you asked: > In Guile's digest I noticed a comment about replacing libltdl (see below) > with the standard `dlopen' interface and providing a shim for systems not > supporting it directly. > > Do Guile's observations apply in general?
libltdl provides two features: - portability of opening shared libraries, - the same functionality with static linking [1]. If guile used libltdl for portability only, then nowadays there is little point in using it on most platforms: - macOS nowadays has dlopen() (and it works even though the argument in macOS 11 is no longer a file name, just a specific string), - HP-UX is dead, - all other Unix platforms (ELF-based ones, and Cygwin) support dlopen(), - native Windows has LoadLibrary instead of dlopen(). So, a simple code with #if and two branches for - dlopen based code, - LoadLibrary based code, is totally sufficient nowadays. > Would it make sense for the > Gnulib project to provide such a shimmed version of `dlopen' making libltdl > obsolete? Hardly. It is impossible to translate a string like "libfoo.so" to "something.dll" automatically; therefore native Windows support needs a #if anyway. A Gnulib module for dlopen() would therefore not bring much simplification. And most dlopen, dlsym options (like RTLD_LAZY) cannot be supported in Windows. Bruno [1] https://www.gnu.org/software/libtool/manual/html_node/Dlpreopening.html