Re: Guile 1.5.6 beta available for testing.

[Rob Browning]

Steve Tell <address@hidden> writes:

> Is it possible to build guile-1.5.6 and install it into a private prefix
> on a system that already has guile-1.4 shared libs in /usr/lib?

I think you should be able to, though you might need to purge your
existing libguile-dev (or guile-dev, whatever RedHat names the
separate dev package, if there is one).

You also should make sure that you have guile's lib directory in your
LD_LIBRARY_PATH when you try to run your new guile

  LD_LIBRARY_PATH=/usr/guile-1.5.6/lib:${LD_LIBRARY_PATH} guile

though guile may do this itself -- I can't recall off the top of my
head.  In either case...

> I guess this may be more of a libtool problem, but is there any hope
> of helping libtool do the right thing here?  I'm certain that I
> don't know nearly enough about why libtool does what it does.  But
> it seems that using -L and -l and hoping for ld to find the right
> things is inherently dangerous here.

Yes, libtool probably shouldn't be doing this, though this problem's
not specific to libtool.  As an example, guile-config used to output
-L/usr/lib and -I/usr/include.  I've fixed that for 1.5.X. -- no
foo-config script should ever specify these flags, since it prevents
you from being able to override a system install of any package during
a build, but a lot of people, including me, didn't realize that at
first :>

If I get some time I'll look in to this and see what's going on,
though if someone else has a chance, that would be great.

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