Re: Fwd: guile-devel Digest, Vol 221, Issue 18

[Bruno Haible]

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