From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile 1.5.8 beta available for testing. Date: 29 Aug 2002 21:58:02 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87adn5said.fsf@zagadka.ping.de> References: <87adn9plqf.fsf@raven.i.defaultvalue.org> <87hehdmu70.fsf@raven.i.defaultvalue.org> <87wuq9sdec.fsf@zagadka.ping.de> <0208291417451J.19624@locke.free-expression.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030651079 448 127.0.0.1 (29 Aug 2002 19:57:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 19:57:59 +0000 (UTC) Cc: guile-devel@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 17kVQM-00006m-00 for ; Thu, 29 Aug 2002 21:57:50 +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 17kVRk-0000O0-00; Thu, 29 Aug 2002 15:59:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kVQb-0000Fc-00 for guile-devel@gnu.org; Thu, 29 Aug 2002 15:58:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kVQZ-0000FG-00 for guile-devel@gnu.org; Thu, 29 Aug 2002 15:58:05 -0400 Original-Received: from dialin.speedway42.dip130.dokom.de ([195.138.42.130] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17kVQZ-0000F7-00 for guile-devel@gnu.org; Thu, 29 Aug 2002 15:58:03 -0400 Original-Received: (qmail 23613 invoked by uid 1000); 29 Aug 2002 19:58:02 -0000 Original-To: Lynn Winebarger In-Reply-To: <0208291417451J.19624@locke.free-expression.org> Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1200 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1200 Lynn Winebarger writes: > The problem is for people who muddle with several development > projects at once. You might want to test development versions of > both libfoo and the libfoo dependent appbar concurrently in > /usr/local, but still want appbar to use the stable version of > libfoo in /usr/lib because appbar has enough instability of its own. The stable and unstable versions of libfoo should have different major version numbers, so there should be no conflict. You would need to compile two versions of appbar, one that is linked against the stable version of libfoo and one that is linked against the unstable one. In my view, shared libraries are in a flat namespace. Conceptually, they are all in a single 'virtual' directory. This single directory is constructed from multiple 'physical' directories by merging them. Ideally, this merging should happen in the filesystem, via somekind of unionfs, say, but normally, it is just done with LD_LIBRARY_PATH or something else and some rules that are not consistently followed by the several library-accessing tools. You might want to have different environments, each with it own way to construct te single virtual library directory, but a program should not try to put itself into its own environment. That will lead to chaos, in my opinion. The best we can do, is to make the rules for constructing the library directory consistent. It is silly that ld finds its libraries in different places as ld.so, for example. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel