Re: A versionized variation on `lt_dlopen ()'

[Ralf Wildenhues]

Hi Ludovic,

* Ludovic Courtès wrote on Tue, Sep 27, 2005 at 06:25:34PM CEST:
> 
> After reading a recent thread on `guile-user',

Can you give a pointer to the thread?  I couldn't find it easily (i.e.,
within one minute :)

> it occurred to me that
> `lt_dlopenext ()' doesn't allow to pass information about the version of
> a module that is requested.
> 
> This is quite unfortunate, especially for Guile, since Guile modules
> load C libraries using `dynamic-link' which is roughly the Scheme
> version of `lt_dlopenext ()'.  This precludes having several versions of
> a given extension installed at once since each of these versions need to
> load a particular version of its companion C library.

Erm, I may be misunderstanding, but you actually have several libcs
lying around which you choose to load from (for other libraries, I'd
understand, but libc)?  This question is of course independent of your
actual request.

> So, I think it would be very nice to have something like:
> 
>   /* Open a module with the file name FILENAME which is compatible with
>      revision REVISION of interface INTERFACE.  The module should have
>      been linked with `-version-info'.  */
>   lt_dlhandle lt_dlopen_version (const char *filename,
>                                  unsigned interface,
>                                  unsigned revision);
> 
> And similarly for `lt_dlopenext ()'.  And I believe this may also be
> useful for other kinds of programs, like programs that use plug-ins (for
> instance, plug-ins could be compiled with a `-version-info' that
> reflects the version of the plug-in API exposed by the program).
> 
> What do you think?

A couple of thoughts: For one, you'd need to use the .la files to open
the modules then (with the current functions, you can also open the
plain .so or whatever it's called).  This is probably not a big
constraint for your use.  For another, static linking (dlpreopening) of
more than one version of the module would not work, but that is nothing
new.

Other than that, it sounds like a reasonable idea to explore post-2.0.
I believe, though, you should use INTERFACE only to decide which one to
open; the function would then search for a module where INTERFACE lies
between CURRENT-AGE and CURRENT, and try to open that.  If there are
multiple matches, I'm not sure what would be best: among modules
differing only in REVISION, obviously the highest would be best.
Other than that: Assuming that, with increasing CURRENT, CURRENT-AGE
would also be non-decreasing, it should probably select the one with the
highest CURRENT, I guess.  (The CURRENT comparison would obviously have
higher precedence than the REVISION comparison.)

Side issue: When we fix preopening to not need the .la file at all,
we'll also have to store the version information then.

I must admit that I haven't thought all the way through this.

Cheers,
Ralf