add-on lib versioning (concrete example g-wrap) -- what to do?

[Rob Browning]

So a concrete case for our add-on library policy which unless I'm
overlooking something obvious, raises some important questions about
our current position (which I fear may be untenable, but I'd like a
sanity check).  There's a broader issue here, but practically
speaking, the question I have to answer *right now* with respect to
g-wrap is pretty straightforward.

I have to settle on versions for the libraries in the latest release
of g-wrap.  There are a number of libraries, but lets consider just
one, libgwrap-glib.so, which depends on both libglib and libguile, and
it can be built against either guile1.4 or guile1.6 (and perhaps
multiple major releases of glib, but that's not relevant here).

So how do I pick the soname for this library?  Say I pick 1 and then
you (the user) configures and builds gwrap against guile 1.4, and ends
up with libgwrap-glib.so.1.

OK, so presume other apps are then built against guile 1.4 and gwrap
and installed on the system.  Now say you install guile 1.6 and
rebuild g-wrap against 1.6, which again produces libgwrap-glib.so.1,
but this one is linked against libguile from 1.6.  Now you have a file
conflict.  You can't install the new libgwrap-glib.so.1 without
breaking any apps or libs on your system that are still linked against
and using the old libgwrap-glib.so.1 and the old libguile9.

So what to do?  To fix this you need to end up with two copies of
libgwrap-glib either with different names, or different sonames.
However in discussions in the past, we've rejected the first solution
-- the idea of embedding the guile version in the library name.
i.e. libguile1.6-gwrap-glib.

So that just leaves the different soname approach (i.e. compile the
guile 1.4 and guile 1.6 linked versions of libgwrap-glib with
different sonames), but how do we portably handle that?  Do I pick the
soname at configure time, somehow based on the version of libguile
that libgwrap-glib is about to link against?  Do all add-on libs have
to do this?  If so, then all add-on libs are going to have to follow
the same restrictions that we've agreed to for internal guile libs,
which means that (1) they may *not* change their major soname during a
guile stable series, and (2) they *must* change their major soname
whenever guile has a new major release and consequently changes its
major soname.  i.e. all add-on libs will have to remain in lock-step
with guile library version-wise.

Perhaps I'm wrong, but this seems like it might be restrictive enough
to significantly stifle development, and it isn't really much
different than just requiring the add-on libs to put the guile version
number in their name -- which makes the rule explicit while still
leaving the add-on libs the flexibility to change their major-soname
if they need to.  Note I'm not necessarily suggesting we should switch
to the policy of embedding the guile version in the add-on lib name,
just pointing out that of the above two choices, it accomplishes
roughly the same thing and is perhaps clearer since it's more
explicit.

(Of course you could just say that you can't have two copies of gwrap
 on the same system, but even so, that still leaves open the question
 of how the soname should be chosen -- since even across machines of
 the same arch, the same soname is supposed to indicate ABI
 compatibility.)

All that said, I'm not quite sure what a better solution would be[1].
I'm just still somewhat worried that guile might be painting itself
into a corner here, though I'd love to be proven wrong.

FWIW I'd also like to point out that this is definitely a point
against guile in the broader "which language should I use for X
project" arena.  I've actually seen it have a negative impact.  I also
suspect that unless we address this, it's may be difficult for our
outside guile-core "add-on" base to grow and maintain much long-term
stability.

[1] The only contenders I can think ATM of are

    - put the guile version in the add-on lib name.

    - use a /usr/lib/guile/VERSION/ subdir for add on libs and just
      figure out and deal with the -L/LD_LIBRARY_PATH/rpath issues.

    - more radically, drop the idea that people will directly link via
      gcc/ld against guile libs, and require some kind of run-time
      dlopen/dlsym/function-pointer-patchup initialization.  i.e.

        scm_make_u8_vector = scm_lt_dlsym (srfi_4_lib, "scm_make_u8_vector");

      or similar.    

    The first two are probably the least intrusive if we can work out
    the details.

Thoughts?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4