Re: A versionized variation on `lt_dlopen ()'

[Ludovic Courtès]

Hi Ralf,

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 .

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 .

> 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".

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

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?

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.

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

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?

Thanks,
Ludovic.