Re: Better support for transition to guile-1.6

[Rob Browning]

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

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.

Presuming we're not going to assert the above, I really think we have
to address the library versioning issue.  As an example, lets say that
guile 1.6 is released, and it needs libguile-srfi-X.so, major version
3, and libguile-srfi-Y.so, major version 4.

Now lets say that guile 1.8 is released and it still needs
libguile-srfi-X.so version 3, but now it needs libguile-srfi-Y.so,
major version 5.

If we want to allow users to have both guile 1.6 and guile 1.8
installed at the same time.  Then both versions will have all their
libsrfi* libs in /usr/lib.  In that case, how will srfi-Y.scm ask for
libguile-srfi-Y.so, major version 5 since both libguile-srfi-Y.so.4
and libguile-srfi-Y.so.5 are both in /usr/lib?

There are a number of ways we could handle this, but I think we need
to have a solid, documented, well thought out approach before we
release 1.6.  I'm already having to consider this issue with g-wrap,
which provides a couple of shared libs, one which is dynamic-linked.

Note too that if we fully version all of the shared libs in guile,
then distributions will have to break guile up into a much larger
number of packages, i.e. for Debian, in addition the libguile10
package, we'd have to have a new binary package for each of the
module-supporting shared libs.  Currently that would add:

  libguile-srfi-srfi-4-0
  libguile-srfi-srfi-13-14-0

and if we really do expect people to be able to link directly against
these libs, we'll also have to have:

  libguile-srfi-srfi-4-dev
  libguile-srfi-srfi-13-14-dev
  
As it is, I'm already going to have to add 

  libqthreads0
  libguilereadline0

and maybe

  libqthreads-dev
  libguilereadline-dev

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.

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.

Another alternative would be to augment dynamic-link so that you can
specify the particular interface number (i.e. the libtool interface
number, which is *not* necessarily the major version number) that you
expect.  Then it would be OK to have all the libs in /usr/lib, but
we'd still have the packaging granularity issues to consider.  The
problem with this is that lt_dlopen doesn't support specifying the
interface number you need (though it should) -- but until it does (I'm
going to bring it up with them) -- we might be able to approximate it
on most platforms by turning this

  (dynamic-link "libfoo" 4)

into this:

  (lt-dlopen "libfoo.so.4")

though that's not really quite right.

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.

Thanks

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