Re: Better support for transition to guile-1.6

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> This also touches on the issue of versioning modules, in general.  You
> might also want to specify a version or interface number when using a
> module.

I tend to think that's a good idea too, but for some reason I thought
I was in a minority on that front.  If not, then great.  It seems like
a good idea to me.  Actually, if we'd had this and lt_dlopen
versioning, we wouldn't have had to write the gnc-module stuff that we
recently added to gnucash.

To get around the .so identity issue, we just scan all the directories
in GNC_MODULE_PATH looking for .la files.  When we find one, we
dynamic-link it and then look for a "gncmod_version" function.  If we
find gncmod_version, then we call it, and see what it returns.  Then
we unlink the library and update a table containing all the available
gnc modules names and versions, along with their respective fs
locations.  Then whenever someone tries to gnc:module-load (or
gnc_module_load) a given module and interface, we can check and see if
any of the available shared libraries provide that module and
interface.

This, of course wouldn't work for shared libraries that we don't have
control over, but it works well otherwise, and it might be a solution
we could apply for guile-specific libraries that would let us sidestep
the libtool issue.

(Though after thinking about your comments below, I realize that
 because of the non-versioned .la file issue, for now, you'd have to
 keep different versions of each lib in separate directories when
 using the above approach.)

> I'd rather have dynamic-link take keyword arguments, but the
> interface version might be important enough to make it an required
> argument, as you say.  On the other hand, we should also have a way
> to dynamically link non-libtool libraries, and interface numbers
> don't make sense for all shared libraries, right?  With a keyword
> argument we would also have a better path to introduce different
> ways of specifying which version of a library to open.

Perhaps it would be better to have two functions, one for when you're
using our versioned API scheme, whatever that turns out to be, and one
for when you just want explicit, traditional dlopening.

> What about starting to maintain our own version of libltdl and
> working with the libtool crowd to port our changes back into the
> official sources?

Maybe -- see below, but so far the libtool list has been kinda quiet
when I've asked about some of these issues, but I just tried again
today.

> But do you think all we need is some code to implement libtools
> interface selection algorithm?  Wouldn't we need to select from a
> set of ".la" files to get all features of libltdl?  As far as I
> understand it, we need ".la" files to make up for the deficiences of
> various shared library implementations, and assuming that one ".la"
> file covers all versions (i.e., all versions depend on the same set
> of external libraries) is not likely to work.

Hmm.  That's a tougher question, and I'm not sure of the answer.  I
must admit that every now and then I forget about the possible
nastiness on other platforms where ldso doesn't handle things sanely
for you.

Presuming you're right, then you'd have to have versioned .la files
too, and I'm not sure how much work that would be.  If we could get
that to work by just hacking our own ltdl.c to look for
libfoo.la.X.Y.Z -- i.e. apply the same search algorithm that's used
for share libs -- and then tell people to "cp libfoo.la
libfoo.la.X.Y.Z when installing their lib, then that might not be too
bad, but I'm still not sure it's workable -- we *need* to be using the
main system installed libltdl when it's available or apps that have
shared libs that also call libtool functions (i.e. gnucash) may end up
with some nasty failures caused by library mismatches between shared
libs.  So given this situation, I tend to think that the fix has to be
handled upstream, or by some mythical libtool replacement.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD