Hello Ralf,
Ralf Wildenhues <[EMAIL PROTECTED]> 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.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
