Re: A versionized variation on `lt_dlopen ()'

[Ludovic Courtès]

Hello Ralf,

Ralf Wildenhues <address@hidden> writes:

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

Right.  The main problem is: a module's dynamic library has to be linked
against a given version of libguile.  The best solution to this (IMO),
rather than a versionized dlopen trick like the one I suggest, is to put
the said library in, e.g., /usr/lib/guile/MAJOR.MINOR .  And then
Guile's module loader would dlopen libraries found there by default.

> And only because you
> have different module loader interfaces, you put modules with according
> different interfaces there?

Yes, the "module loader" being libguile.

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

Well, that's where the versionized `lt_dlopen' could come in handy: the
Scheme side of a module could tell precisely what version of a shared
library it wants to dlopen.

(Then Guile doesn't currently provide any tool to support versioning of
the module itself, but that's another story.)

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

Sure.

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

I haven't thought about this very deeply either in fact.  ;-)

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

Right, this would certainly make it hard to reconstruct the
interface/revision/age tuple in all cases.  Hence the incentive to use
`.la' files to get this information.

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

Ok.

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

Yes.  In the worst case, the `.la' files could still be used for that,
right?

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

Well, the more monolithic `lt_dlopen_version ()' ("give me this
interface") would need to do that "scanning" anyway.  So exposing the
mechanisms that it relies on doesn't make any difference in that respect
I think.

Actually, I'm unsure whether such races are likely to occur, although
your example is a good one.  ;-)  IMO, in most common cases, especially
when libraries (or plug-ins) are mostly installed by the administrator,
my intuition is that a user would be very unlucky if they experienced
such a race.

And most importantly, I can't think of any way one could avoid this race
to ever happen -- that's why I'm hoping it would be "rare enough".

Thanks,
Ludovic.