From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: Release now? Date: 27 Feb 2003 13:07:09 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <873cm9oe9k.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046369793 4930 80.91.224.249 (27 Feb 2003 18:16:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 18:16:33 +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 18oSa7-0001HN-00 for ; Thu, 27 Feb 2003 19:16:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oSZg-00047X-01 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 13:16:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oSXP-0002pO-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:13:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oSVo-0001tu-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:12:06 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oSR3-0000Ly-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 13:07:09 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 77868864; Thu, 27 Feb 2003 13:07:09 -0500 (EST) Original-To: Rob Browning In-Reply-To: <873cm9oe9k.fsf@raven.i.defaultvalue.org> Original-Lines: 78 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:1998 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1998 To me, it seems like the -L/usr/lib/guile/VERSION solution would allow the same result, but without the library naming issues. You'd have: /usr/lib/libguile.so.9* /usr/lib/libguile.so.12* /usr/lib/libguile.so.14* /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1 /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4 /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2 Just to be sure I understand, is your objection to this primarily a concern with it being an untested approach? I just want to make sure we're on the same page. No, we're not. My objection, deep down, is a philosophical discomfort with linking against a library in one place and expecting the run-time linker to find it someplace else. This just seems to be Wrong and tempting fate. Maybe I just need to get over this - it is probably a remnant from early exposure to systems that stored the whole path, or SunOS where -R was the default automatically from -L. I think I also have an objection to doing things to accomodate people who refuse to use -rpath, since to me the resulting pseudo-requirement to put all libraries in /usr/lib (or use LD_LIBRARY_PATH) is totally unreasonable. Your proposal does seem likely to impose fairly little pain and save a lot. I would like to make sure that one can have different pkg-config files and select the right one, since IMHO pkg-config will replace guile-config eventually. There is a large transition question, though - guile 1.6 already has libraries in a particular place. For 1.8 to have a new place is probably fine, but this would be disruptive to those who have already found a satisfactory solution. Hence my notion of having the version-named midfix be optional, so Debian can use it and NetBSD can keep using separate prefixes. Also, we might consider having a different prefix rather than a 'midfix', which seems awkward. With /usr/lib/guile/1.4, guile/1.4 gets appended to $(libdir). The alternative of /usr/guile/1.4/lib, where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me. This latter scheme is in fact what NetBSD does, except that -rpath is used to find the libguile.so at run time from /usr/pkg/guile/1.4/lib, and it isn't present in /usr/lib/libguile.so. So, setting the prefix, and some optional glue code to symlink in the libs (and guile-config with versions) to the 'real' $(prefix)/lib would probably buy us the best of both worlds. And, there would be a harmonized solution between NetBSD and Debian, modulo the 'use -R v.s. make symlinks in /usr/lib' difference. To me, that bodes well for it working elsewhere. (With 20/20 hindsight, guile really should have got this right long ago, but I didn't contribute code/solution then, so I have no absolutely no right to complain.) Summarizing: If the installed locations of guile 1.6 changes, I object because it will cause work for people who have already coped. I prefer the different prefix rather than a midfix. A configure option to add a midfix seems ok, but given that we already have --prefix, it seems like more work. If the default behavior includes either midfixes or extra symlinks, I object, because it is imposing what some may view as uncleanliness on everyone because some decline to use -R. Differing prefixes and a ./configure option to symlink into another prefix is a clean solution which can be used in varying environments, enabling each to win while preserving their sense of the right way to do things. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel