Using Libtool's `dlpreopen'

Using Libtool's `dlpreopen'

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

Re: Using Libtool's `dlpreopen'

[Neil Jerram]

2008/12/7 Ludovic Courtès <ludo@gnu.org>:
>
> 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.

Sounds good to me.

       Neil

Re: Using Libtool's `dlpreopen'

[Ludovic Courtès]

Hi Neil,

"Neil Jerram" <neiljerram@googlemail.com> writes:

>> 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.
>
> Sounds good to me.

Done.

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=de7d32d064f2178c41dc98540ec5822a286107ae

That said, I think dlpreopen is not useless per se: it allows
`--disable-shared' builds to work, as well as builds on platforms
without shared library support (IIRC Guile is built without shared
libraries by default on HP-UX 11.11).

Thanks,
Ludo'.

Re: Using Libtool's `dlpreopen'

[Neil Jerram]

2008/12/7 Ludovic Courtès <ludo@gnu.org>:
>
> That said, I think dlpreopen is not useless per se: it allows
> `--disable-shared' builds to work, as well as builds on platforms
> without shared library support (IIRC Guile is built without shared
> libraries by default on HP-UX 11.11).

I agree.  But given that you were sure that it had never worked as it
was, and that I have no evidence contrary to that, your change was
only removing cruft, not removing function.

Of course, someone may still choose to invest time in making
--disable-shared really work, if that is important.

Regards,
      Neil