guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.6.0 problems with libguilereadline-v-12 and fix


From: Rob Browning
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: Fri, 20 Sep 2002 10:23:36 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu)

Greg Troxel <address@hidden> writes:

> But guile won't work that way, since it needs to find ice-9/foo.scm.

It will if you set GUILE_LOAD_PATH, which is how we traditionally run
guile from a non-install location (which *is* sometimes important --
see below).

> Your point about apps needing to link with the srfi libs is one I had
> not considered.  If they link at compile time, then one either has
> them in a default path, uses LD_LIBRARY_PATH, or uses -rpath/-R  (or
> loses).  This is exactly the situation for libguile today.

Since libguilereadline isn't intended to be a public library (unlike
all the others), you're right, it's a more likely candidate for
loading via an absolute path (the install path), but if you do that
you're still going to have the same load failures with
libguile-srfi-srfi-4, etc. -- (use-modules (srfi srfi-4)) will fail
just as readline did.  That's why I've been talking about the libs
other than readline.  We might as well have a solution that works for
all the dlopened libs.

However, without some additional special casing, just putting the
absolute install path into readline.scm will mean that you can't run
guile from the build tree (and still use readline), something that
people can do now (using pre-inst-guile, or suitable envt var
settings), and something we need to do if we want "make check" to be
able to test readline before install.

Now one might argue that "make check" is not critical for readline
(though I'd disagree), but I doubt anyone would argue that it's not
critical for the other libraries, and so we have to be able to run
from a non-install directory.  Of course there are other ways we could
accomodate this need, and perhaps we should investigate those, but at
the moment we ended up with envt vars because that's one of the
traditional unix approaches to this sort of thing (we have
GUILE_LOAD_PATH for the same reason).

I'm definitely not opposed to other solutions, and I can think of a
few myself, but if we change things, I want to try to make sure that
we pick a solution that's definitely an improvement and doesn't make
guile's build/install behaviors too much more complex.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]