Re: Better support for transition to guile-1.6

[Rob Browning]

Steve Tell <address@hidden> writes:

> BTW, the following sequence seems to work on redhat 7.1: 
> - start with a stock system 
> - compile and install (or build RPMs for) applications that still
>   only build with 1.3.4 and earlier (such as scwm, still my favorite
>   window manager!) 
> - build a guile-1.4 RPM 
> - install guile 1.4 using "rpm -i --force", thus leaving /usr/lib with
>   both /usr/lib/libguile.so.6.0.0 and /usr/lib/libguile.so.9.0.0.
>   /usr/share/guile already splits things into per-version directories
>   beautifully, so ice-9 still comes out OK.

I've tried to contact RedHat wrt to this, but haven't yet had any
success.  One better way to do this would be for RedHat to handle
things the way that Debian does and provide a separate package for the
guile libraries.  In Debian we have:

  guile1.4
  guile1.4-doc
  libguile9
  libguile-dev
  etc.

This means that you can have libguile6 (i.e. guile1.3.4) and libguile9
(i.e. 1.4) installed at the same time with no conflicts since the
libguile-dev package is the one that has the .so development lib
symlinks.

Until RedHat makes a change like this, they'll always find switching
to a newer version of Guile painful, and will probably try to avoid
it.  If you can't have multiple lib packages installed, then you can't
install a newer guile without recompiling *everything* that depends on
guile.

> The only real hindrances seem to be:
> - libguilereadline.so doesn't have a proper version number, but
>  the 1.3.4 one and the 1.4 one don't mix.  So only one guile binary can
>  use readline.
>  But moving forward past 1.5.*/1.6, I expect similar trouble with the
>  libguile-srfi-*.so's.  Would it be  possible to make their .so version
>  numbers match the one on libguile?

I believe all the 1.5 /usr/lib .so's should be versioned now with
version numbers we can adjust from the makefiles, but we will have to
remember to adjust them.  They're using the libtool versioning scheme.

> My personal preference is to keep working this way:
> - distribution-standard and current-stable guile both installed as
>   packages into /usr on main machine.
> - prerelease guile (1.5.4 now) installed into a totaly seperate --prefix
>   for test builds.

This isn't going to work if you're doing any compilation against other
libraries using the foo-config style scripts to get their compile
options.  In particular, if you use the gnome libs, "gnome-config
--libs foo" will often add a -L/usr/lib to the compile line, and so
you won't be able keep from possibly accidentally linking in your
/usr/lib/ guile libs, even if you wanted your separately installed
guile.  I regularly compile gnucash against guile 1.3.4, 1.4, and 1.5,
and I just had to purge the Debian libguile-dev package and install
all three guiles under a separate --prefix.  Otherwise I would get
/usr/lib/libguile* accidentally, because of gnome-config's -L/usr/lib.

The only solution I could think of for this problem, and I haven't
even had time to make sure I think it would work, though I may suggest
it for discussion on debian-policy, is the following:

  1) Forbid foo-config style scripts from specifying any -L/foo arg
     where /foo is one of the normal ld.so paths.

  2) Require that all lib development packages place symlinks to their
     libs into a package specific directory, i.e. for libguile9, the
     symlinks would go into /usr/lib/libguile9/.

  3) Have the foo-config scripts specify -L/usr/lib/<package> rather
     than -L/usr/lib.

Of course, given libtool's -rpathing behaviors, I'm not sure this
would end up having the desired effect, but it would make sure you're
always linking against the libs you think you're linking against.

The fundamental underlying problem is that the foo-config style
scripts aren't composable if collections of your development libs are
in the same directory, i.e. /usr/lib.

FWIW.

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