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: Thu, 19 Sep 2002 13:47:03 -0500 Sender: guile-user-admin@gnu.org Message-ID: <87it11ddg8.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 1032461270 13782 127.0.0.1 (19 Sep 2002 18:47:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Sep 2002 18:47:50 +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 17s6L5-0003Zz-00 for ; Thu, 19 Sep 2002 20:47:47 +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 17s6LQ-000056-00; Thu, 19 Sep 2002 14:48:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17s6KQ-0008UB-00 for guile-user@gnu.org; Thu, 19 Sep 2002 14:47:06 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17s6KO-0008Th-00 for guile-user@gnu.org; Thu, 19 Sep 2002 14:47:05 -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 17s6KN-0008TV-00 for guile-user@gnu.org; Thu, 19 Sep 2002 14:47:04 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 6279C4425; Thu, 19 Sep 2002 13:47:03 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 4DD595DD; Thu, 19 Sep 2002 13:47:03 -0500 (CDT) Original-To: Greg Troxel In-Reply-To: (prj@po.cwru.edu's message of "Thu, 19 Sep 2002 11:57:56 -0400") Original-Lines: 51 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:1034 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1034 prj@po.cwru.edu (Paul Jarc) writes: > I think the right thing is for libltdl to respect *all* of ld.so's > mechanisms, for the sake of simplicity - you won't have to worry about > which one is being used when you want to configure something to find > libraries somewhere. Any problem that can occur with -rpath can > already occur with ld.so; any solution for ld.so ought to be usable > with (the hypothetical fixed) libltdl as well. That would be fine with me -- frankly I tend to think that runtime library linking and compile-time library linking should be handled by the *same* set of people/tools, but we're certainly not there yet :< > I really don't like such *-config programs. If package foo links to > libraries from package bar, I want foo to find bar via a path other > than bar's installation prefix. I set up a symlink to bar for foo to > use. Then when I install a new version of bar (with its own unique > installation prefix), I update the symlink (atomically, even) and foo > finds the new version. I'm not sure I completely follow. >> As I recall, the reasoning for this was that from a system >> integrator's perspective, using an rpath causes major problems. >> Libraries will need to be moved around from time to time and if you >> use rpath, you make it impossible to do this >> transparently/incrementally. > > I'm a system integrator too, and I use rpath extensively. I don't > move libraries or anything else around post-installation. I don't fully recall the arguments/rationale, though you could check the debian-policy or debian-devel archives for more details if you care (I believe most of this debate pre-dates the debian-policy list). My impression was that there were times when moving libraries (over the years) was very hard to avoid, and being able to avoid doing it en-masse, was somehow a fairly large win. Perhaps there are some smart ways to avoid the whole issue, but think that we should be careful about ignoring this without some investigation. It's been my experience (over a long period of time) that debian often has very good reasons for many of its policies. Also, what I can say for sure is that unless debian dolicy has changed, relevant bits of anything that's pacakged for debian will have to be modified to not set -rpath. -- 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