Re: Better support for transition to guile-1.6

[Steve Tell]

On Tue, 23 Oct 2001, Rob Browning wrote:

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

Perhaps including an RPM .spec file in the distribution that builds things
the preferred way go further than verbal arguments.  I've hacked up my own
guile-1.4 RPMs; I'll see what I can come up with.

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

I seem to recall reading that RH policy is that they avoid breaking binary
compatibility across minor releases - so unless guile 1.4 or 1.6 can run
programs compiled under guile-1.3.4, they're stuck with the old one until
8.0.  
But just because they won't ship two guile versions doesn't mean we
can't cook up a good way for multiple ones to coexist for simple user
upgrades, thus making applications that don't want to support the old
versions simpler for users to install.



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

Any reason not to make the numbers match up across the board, and have
configure substitute all of them at once?

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

Ouch! I hadn't thought of that.

> guile.  I regularly compile gnucash against guile 1.3.4, 1.4, and 1.5,

(Good to know that we can study gnucash for version compatibility hints!)

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

Your suggestion for fixing the foo-config style scripts sounds plausible
and worthy of discussion or trial implementation.

I think its worth some effort so that multiple versions can coexist and
"serious developers" can use their distributions's package system and not
have to switch to a radicaly different setup from what "causual
program-compilers" are likely to have.

Steve

--
Steve Tell  address@hidden