guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better support for transition to guile-1.6


From: Marius Vollmer
Subject: Re: Better support for transition to guile-1.6
Date: 29 Nov 2001 22:39:10 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Rob Browning <address@hidden> writes:

> So I'd like to propose the following, and if no one objects (or
> volunteers), I'd like to start working on this, or on whatever else we
> decide would be better:

Yes, I agree (with the comments below).  Having a way to specify an
interface number when dynamically loading a library is just plain
necessary.

This also touches on the issue of versioning modules, in general.  You
might also want to specify a version or interface number when using a
module.

>   1) augment dynamic-link (or a new function) to take an interface
>      number as an additional argument.  This argument will be optional
>      for now, but if deprecation is on, a warning will be issued if it
>      isn't specified.  So we'll have (dynamic-link "foo" 4).

I'd rather have dynamic-link take keyword arguments, but the interface
version might be important enough to make it an required argument, as
you say.  On the other hand, we should also have a way to dynamically
link non-libtool libraries, and interface numbers don't make sense for
all shared libraries, right?  With a keyword argument we would also
have a better path to introduce different ways of specifying which
version of a library to open.

>   2) provide a libtool module (when the platform supports it) which
>      provides the raw lt-dlopen, lt-dlsym, etc. functions.

See below.

>   3) For now, on most platforms, if not all, (dynamic-link "foo" 4)
>      will perform the same work that libtool does, searching
>      LTDL_LIBRARY_PATH and LD_LIBRARY_PATH, etc. to find a library
>      satisfying libfoo interface 4, bottoming out in either failure,
>      or a call like (lt-dlopen "/some/dir/libfoo.so.4").

What about starting to maintain our own version of libltdl and working
with the libtool crowd to port our changes back into the official
sources?

That way, I don't think we need a separate lt-dlopen, do we?


But do you think all we need is some code to implement libtools
interface selection algorithm?  Wouldn't we need to select from a set
of ".la" files to get all features of libltdl?  As far as I understand
it, we need ".la" files to make up for the deficiences of various
shared library implementations, and assuming that one ".la" file
covers all versions (i.e., all versions depend on the same set of
external libraries) is not likely to work.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]