From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.bugs Subject: Re: cvs guile build/install problems Date: Thu, 28 Mar 2002 02:30:57 -0500 Sender: bug-guile-admin@gnu.org Message-ID: <0203280230570L.17464@locke.free-expression.org> References: <02030414141506.10124@locke.free-expression.org> <02031601240708.17464@locke.free-expression.org> <878z8m29hw.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1017300980 14212 127.0.0.1 (28 Mar 2002 07:36:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2002 07:36:20 +0000 (UTC) Cc: bug-guile@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16qUSK-0003h7-00 for ; Thu, 28 Mar 2002 08:36:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16qUS7-0007WG-00; Thu, 28 Mar 2002 02:36:07 -0500 Original-Received: from epimetheus.hosting4u.net ([209.15.2.70]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16qUPv-0007MM-00 for ; Thu, 28 Mar 2002 02:33:52 -0500 Original-Received: (qmail 2709 invoked from network); 28 Mar 2002 07:33:49 -0000 Original-Received: from leo.hosting4u.net (HELO free-expression.org) (209.15.2.51) by mail-gate.hosting4u.net with SMTP; 28 Mar 2002 07:33:49 -0000 Original-Received: from locke.free-expression.org ([156.56.123.162]) by free-expression.org ; Thu, 28 Mar 2002 01:33:46 -0600 Original-To: Marius Vollmer X-Mailer: KMail [version 1.2] In-Reply-To: <878z8m29hw.fsf@zagadka.ping.de> X-Rcpt-To: Errors-To: bug-guile-admin@gnu.org X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GUILE, GNU's Ubiquitous Extension Language List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.bugs:62 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.bugs:62 On Wednesday 20 March 2002 16:51, Marius Vollmer wrote: > Sorry, I tested with the wrong file. But automake will also install > doc/tutorial/mdate-sh for me: > > $ rm doc/tutorial/mdate-sh > $ rm doc/ref/mdate-sh > $ ./autogen.sh > autoheader2.50: libguile/scmconfig.h.in is unchanged > doc/ref/Makefile.am:24: installing `doc/ref/mdate-sh' > doc/tutorial/Makefile.am:24: installing `doc/tutorial/mdate-sh' I haven't tracked down the specific problem, but I can say that invoking autogen.sh twice will install doc/tutorial/mdate-sh the second time (but not the first when it's right out of CVS). It installs doc/ref/mdate-sh the first time. I'm making a separate copy of the directory for building. > Could you investigate why this doesn't happen for you? > > > However, it does appear your search function still looks in > > /usr/local/share/guile/1.7.0 for shared libraries. > > Could you give a test case and strace or whatever so that I can try to > reproduce this behavior? > Sorry, my fault. I must have invoked the stable guile that time because I haven't been able to get the cvs version to find the libraries without an env variable set. > Hmm, I'm not sure. We leave all our library searching to libltdl, and > libltdl might not have been configured with the same libdir as Guile. > I also think that creating shared library universes that are local to > a program will not work as well as globally configuring the shared > library system in a consistent way. Maybe. But modules aren't really the same as shared libraries - other programs don't need to be snooping around guile modules and guile shouldn't be snooping in other programs' modules. Hypothetical situation: A program links to guile and another interpreter, which also uses libtool. Both have modules named .so, but they are not the same. However, if both rely on the LTDL_LIBRARY_PATH variable, only one will be found and it will be the wrong one for one of the interpreters. Ok, it's unlikely with a disciplined naming scheme, but that's ugly. It's also probably why ltdl searches paths given by the program before searching the paths given by the environment variables (which seemed backward to me at first). It's also remotely possible that someone would write a setuid guile script that gets passed munged environment variables where some user has set up bogus modules. Not terribly likely I know. But when I have a sysadmin hat on I always prefer being able to require dynamically loaded code come from a known and trusted location (at least in production usage). I'm paranoid that way. But mostly I'd just like it to work without having to set environment variables that I don't otherwise have to set (my LD_LIBRARY_PATH is empty - that's what ld.so.conf is for, except in special cases). Lynn _______________________________________________ Bug-guile mailing list Bug-guile@gnu.org http://mail.gnu.org/mailman/listinfo/bug-guile