Using Libtool's `dlpreopen'

[ludo@gnu.org (Ludovic Courtès)]

Hello!

In `libguile/Makefile.am', we have:

  guile_LDFLAGS = @DLPREOPEN@ $(GUILE_CFLAGS)

where "@DLPREOPEN@" is "-dlpreopen force", which has no effect.  Looking
back into the history, it was added in commit
6165ede38b4cfd18ee9530505f7a2cb5d5dc58e7, dated 2000-01-10, but there's
no explanation of why it was added.  The `LTDL_SET_PRELOADED_SYMBOLS ()'
line in `guile.c' was itself first added on the same day in commit
4ed6bae2fcb1ccb20de478842aa49e5fe7f751f1, but again, it couldn't have
any effect since no libraries to be preloaded were specified at link
time.

The correct usage would be something like:

  -guile_LDFLAGS = @DLPREOPEN@ $(GUILE_CFLAGS)
  +guile_LDFLAGS = $(GUILE_CFLAGS) \
  +  -dlopen $(top_builddir)/srfi/libguile-srfi-srfi-1-v-@LIBGUILE_SRFI_SRFI_1_MAJOR@.la

but the problem is that the `srfi' directory must be built after
`libguile', because it uses `libguile.la'.  The only solution with the
current recursive `make' structure would be to add something like:

  guile: guile.lo libguile.la $(top_builddir)/srfi/libguil...la
         $(MAKE) -C $(top_builddir)/srfi
         $(LIBTOOL) --mode=link $(CC) -o $@ libguile.la $(guile_LDFLAGS)

This solution sucks a little bit, as it adds yet another recursive
`make' invocation.  It would be more elegantly solved with a single
top-level Makefile, I think.

Thus, given that:

  1. Dlpreloaded symbols have never worked.

  2. There's no clean way to make use of them.

  3. The `LTDL_SET_PRELOADED_SYMBOLS ()' macro causes compatibility
     issues between <ltdl.h> 1.5 vs. 2.2.

I'm in favor of simply removing `-dlpreopen' and
`LTDL_SET_PRELOADED_SYMBOLS' for now.  If we agree on that, then I'll
release 1.8.6 this way.

Thanks,
Ludo'.