Re: Better support for transition to guile-1.6

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> (I may be wrong, but I think that we should hold off on 1.6 until we
>  this issue is fully resolved, or we may find ourselves making a mess
>  that will be hard to clean up later.)

(Hmm, I don't think waiting for something to be _fully_ resolved is an
 implementable goal.  There will always be one last sticky thing...)

> Marius Vollmer <address@hidden> writes:
> 
> > Rob Browning <address@hidden> writes:
> >
> >> Since these libs aren't public, there may be no point to having them
> >> in /usr/lib and dealing with the complexity of careful libtool
> >> versioning.
> >
> > The libs _are_ public, in my view. (`The libs' being shared libraries
> > that are loaded via `load-extension'.)  They might not look like they
> > are right now, but as soon as you want to link other compiled code
> > with these libraries, you will likely run into problems when the
> > libraries are special, in any ever so small way.
> 
> So we're not going to just assert that our dynamic-linked shared libs
> (i.e. all those but libguile and libqthreads ATM) may not be accessed
> directly from C, but only via their guile interface?  That's one
> (possibly too draconian) solution.

Right.  In my experience with guile-gtk, this will not work.  For many
shared libraries, it might work, but it wont work for all.  I.e., many
shared libraries will exclusively be used as an `extension' (that is,
loaded via load-extension), but some will also be used as a normal
shared library, as an argument to ld.

We could rule that shared libraries need to be strictly separated into
two classes: one class would be that of libraries that are
`extensions' and they are not meant to be used as regular shared
libraries.  We might call them plugins.  The other class would be
libraries that can be linked into programs or other libraries, but
could not be used as extensions.  `load-extension' would not deal with
these real libraries at all.

If you have a body of code that wants to be both, a plugin _and_ a
real library, you would need to write both: a real library and a
smallish plugin that just uses the library.  That might not be a bad
arrangement, but I think it is sufficiently easy to have shared
libraries that are a plugin and a real library at the same time.

(uhh, not very concrete, eh?)

> Presuming we're not going to assert the above, I really think we have
> to address the library versioning issue.

Yes.  As you say, `dynamic-link' and `load-extension' needs to be able
to request particular versions of a shared library.

I think we should work with the libtool guys to add this feature to
libltdl or libtool as a whole.  Off hand, I think the libtool would
need to be changed so that multiple versions of a ".la" file can be
installed simultaneously.

Before we have that feature, we can make sure that passing an absolute
file name to `load-extension' without an extension will work.  We can
then tell people that need to distinguish between multiple versions of
a plugin that they can install each version into their own directory,
and pass the absolute filename (without ".so" suffix etc) to
`load-extension'.

> But I think we need to be sure we really do want to handle all the
> complexity involved with maintaining each of our shared libs as a
> public library that people are supposed to use directly, even if
> it's just dynamic-linked from a guile module, and only intended to
> support that module.

One feature of Guile is that it has both a Scheme and a C API.  This
is seen as one of its strengths, and I think it would be good to offer
this for as much parts of Guile as possible.

> As I think I've mentioned before, one alternative to this would be to
> say that all the shared libs that ship with a particular guile release
> that are dynamic-linked (i.e. not libguile or libqthreads) are not
> versioned, and are not to be linked against "outside" binaries or
> libraries.  We would then put these libs into /usr/lib/guile/1.6/, for
> example, and we would only have to worry whether or not these libs are
> consistent with each other for a given release.

Yes.  We can do this nevertheless, on a library by library basis.  It
wouldn't be ideal, but it would work until we have...

> Another alternative would be to augment dynamic-link so that you can
> specify the particular interface number

...this.

> Anyway, in the end I'm not too concerned about *which* policy we
> chose, just that we choose one while understanding the ramifications,
> and stick to it.

I think the current way of doing it assumes very little on the part of
Guile itself, and gives people the freedom to roll their own,
including isolating plugin style libraries so that they don't clash
version wise.