Re: A versionized variation on `lt_dlopen ()'

[Ralf Wildenhues]

Hi Ludovic,

* Ludovic Courtès wrote on Wed, Sep 28, 2005 at 06:05:40PM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > Can you give a pointer to the thread?  I couldn't find it easily (i.e.,
> > within one minute :)
> 
> Probably because it's inappropriately entitled.  ;-)
> 
> It starts here:
> http://lists.gnu.org/archive/html/guile-user/2005-09/msg00061.html .

D'oh.  I even looked at that one, but only at a glance, and decided
too quickly that it wouldn't be the right one.

> And I tried to summarize the issues that may be relevant to `libltdl'
> there:
> http://lists.gnu.org/archive/html/guile-user/2005-09/msg00090.html .

Thank you for the pointer and the summary.

Do I understand correctly that the problem discussed there does not
really revolve around different interfaces of the module you try to
load, but first of all of the module loader?  And only because you
have different module loader interfaces, you put modules with according
different interfaces there?

(Wonder if you can guarantee interface stability of the actual module
over its life time; luckily that's nothing I have to worry about :)

> > 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.
> 
> I meant "C library" in the general sense, i.e. a library written in C,
> unlike in "the GNU C library".

OK.

> > 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.
> 
> For Guile and other plug-in-like usage patterns, we don't really care
> about ``dlpreopening'': the point is precisely to load things
> dynamically.

Surely.  For libltdl, we don't mind providing functionality that works
better with shared objects, but we're extra happy and try hard to make
the functionality degrade gracefully in the dlpreopening case.  Here,
you could work in static-only systems without changing your code (which
is good!), you just couldn't use multiple versions any more.

> Aside from that, why would we need the `.la' files to open a specific
> version of a library?  Doesn't the library file name precisely reflect
> its interface/revision/age?

Did I mention I haven't thought about this fully?  :-)
(Still couldn't, so please regard this as more of a brainstorm.)

Yes, you are certainly right that you do not necessarily need the .la
files.  But the .la files make life a lot easier for this issue:
Without it, we need to encode the mapping
  interface/revision/age -> soname
into libltdl C source (wonder if revision is ever used here).  And then
I'm still not really sure if we can reconstruct this in each and every
case, we might have to look at both the soname and symlinks.

Please note that the way the soname is constructed differs from system
to system, in ways you might not entirely expect.

Also please note that Keith Packard recently suggested a patch which
allows to separate the soname from the file name, so that the link time
name and the runtime name may be different.  (In the special situation
he described this can be useful.)  We need to think about if/how these
two features could work together or not.  (Possibly there's nothing to
worry about here; I'm mentioning it as a reminder for the archives.)

> In any case, whether `libltdl' needs to read a `.la' file in order to do
> the job is not something the user should worry about.

Agreed.

> > 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.)
> 
> Actually, the REVISION argument is optional: implicitly, you'd always
> prefer the highest as you said.  So we can probably remove that
> parameter from the function.  Then I guess choosing the interface with
> the highest CURRENT, provided that CURRENT - AGE <= INTERFACE, things
> should work fine.

OK.

> In fact, a more fine-grained API could be exposed, something along the
> lines of:
> 
>   /* Return an array of library files that implement interface
>      INTERFACE.  */
>   lt_dlfile *lt_matching_dl_files (const char *filename,
>                                    unsigned interface,
>                                    size_t *match_count);
> 
>   /* Open the dynamic library represented by FILE.  */
>   lt_dlhandle *lt_dlopen_file (lt_dlfile *file);
> 
> And then, a number of accessors, like:
> 
>   const char *lt_dlfile_file_name (const lt_dlfile *);
>   unsigned    lt_dlfile_interface (const lt_dlfile *);
>   unsigned    lt_dlfile_age (const lt_dlfile *);
>   unsigned    lt_dlfile_revision (const lt_dlfile *);
> 
> With this, users could implement any policy they like.
> 
> Does this sound reasonable?

A couple of comments:
I don't actually know if we can reconstruct all this information, if
we don't have the .la file.

Also, I don't like this "scanning" too much, as it is inherently racy.
By the time you try to open one of these files you've matched, the list
might have changed already.  I'd rather like something along the lines
of "give me this interface", and the return value will say whether that
worked or not; and if it worked, the module is loaded.  Surely in most
settings this race is of little interest; but think of a browser which
allows you to install additional plugins if the necessary versions is
not yet available.

What do you think?

Cheers,
Ralf