From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.user Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix Date: Fri, 20 Sep 2002 10:23:36 -0500 Sender: guile-user-admin@gnu.org Message-ID: <87it108z2f.fsf@raven.i.defaultvalue.org> References: <20020918203311.3C5FA3F28@fnord.ir.bbn.com> <87k7ljgfvd.fsf@zagadka.ping.de> <87d6radoa5.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032555086 9009 127.0.0.1 (20 Sep 2002 20:51:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 20 Sep 2002 20:51:26 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17sUkG-0002L3-00 for ; Fri, 20 Sep 2002 22:51:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17sUke-0007p7-00; Fri, 20 Sep 2002 16:51:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17sPd7-0003p3-00 for guile-user@gnu.org; Fri, 20 Sep 2002 11:23:41 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17sPd4-0003oq-00 for guile-user@gnu.org; Fri, 20 Sep 2002 11:23:41 -0400 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17sPd3-0003ol-00 for guile-user@gnu.org; Fri, 20 Sep 2002 11:23:37 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 09D49A9EE; Fri, 20 Sep 2002 10:23:37 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id B8D99133D; Fri, 20 Sep 2002 10:23:36 -0500 (CDT) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "20 Sep 2002 08:04:22 -0400") Original-Lines: 48 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:1055 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1055 Greg Troxel 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 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user