Re: Better support for transition to guile-1.6

[Steve Tell]

On Wed, 24 Oct 2001, Rob Browning wrote:

> Steve Tell <address@hidden> writes:
> 
> > Perhaps including an RPM .spec file in the distribution that builds things
> > the preferred way [would[ go further than verbal arguments.  I've hacked up 
> > my own
> > guile-1.4 RPMs; I'll see what I can come up with.

Splitting guile-1.4 into seperate RPMS for "libs", "devel" and "guile"
(/usr/bin/guile) was easy enough.  My resulting
guile-libs-1.4-4sgt.i386.rpm installs without conflicts on RH7.1 alonside
RedHat's guile-1.3.4 and allows libguile9-using binaries to run.

Tonight's effort can be seen at http://www.telltronics.org/pub/guile/

(Not a fast link - save a lot of download time by just fetching
guile-1.4.spec and guile-1.4-netdb.patch and using your own guile-1.4.tar.gz)

Pushing this forward to 1.5.4 or cvs-guile is a project for another night.
 
> If they'd accept that, that would be great.
> 
> > 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.
> 
> I'm not sure I understand.  If we're doing our homework, then you
> should be able to install several versions of guile at the same time
> with no problems.  Some apps will link against libguile6 and some
> against libguile9.  I've been trying to make sure that's true in
> Debian, at least, and I think we've been doing fairly well.

Sorry, what I meant was that if they were only to ship one version
standard, it would have to be the same as or binary-compatible with
whatever shipped with the X.0 release.

Once we get things straight, I agree that users should be able to easily
install additional versions for use by 1.4-only or 1.6-only applications.

 
> > Any reason not to make the numbers match up across the board, and have
> > configure substitute all of them at once?
> 
> Alternately, we might want to consider versioning the guile-internal
> lib directory.  i.e. put libsrfiX, etc. into /usr/lib/guile/1.6.1 for
> example, and modify our internal LTDL_LIBRARY_PATH appropriately.

I was able to get libqthreads and libguilereadline pushed into a
subdirectory simply with "configure --libdir=/usr/lib/guile-$VERSION"
Guile itself ran and found libguile OK, but was unable to find additional 
.so's with dynamic-call (for example, libguilereadline).

I'd need to learn more about libtool and dynamic linking in guile to fix
this.

But does it seem reasonable that configure and the Makefiles should always
try to arrange for a libdir that isn't in LD_LIBRARY_PATH or
/etc/ld.so.conf to work for loading the guile-internal libs?

Steve

--
Steve Tell  address@hidden