From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y? Date: Wed, 13 Nov 2002 11:20:37 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87d6p9xu6y.fsf@raven.i.defaultvalue.org> References: <87u1imiste.fsf@raven.i.defaultvalue.org> <871y5qecfp.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 1037209292 32676 80.91.224.249 (13 Nov 2002 17:41:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 17:41:32 +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 18C1W6-0008Up-00 for ; Wed, 13 Nov 2002 18:41:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18C1RX-0006n7-00; Wed, 13 Nov 2002 12:36:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18C1Bz-0001GA-00 for guile-devel@gnu.org; Wed, 13 Nov 2002 12:20:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18C1Bv-0001EK-00 for guile-devel@gnu.org; Wed, 13 Nov 2002 12:20:42 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18C1Bu-0001EG-00 for guile-devel@gnu.org; Wed, 13 Nov 2002 12:20:38 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id CBE88BD8C; Wed, 13 Nov 2002 11:20:37 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 6628624B20; Wed, 13 Nov 2002 11:20:37 -0600 (CST) Original-To: djurfeldt@nada.kth.se In-Reply-To: (Mikael Djurfeldt's message of "13 Nov 2002 10:58:03 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) 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:1698 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1698 Mikael Djurfeldt writes: >> For Debian at least I was packaging things for now so that you can >> only have one guile-X.Y-dev package installed at a time. To do >> anything different would require more upstream changes (including the >> above), and until/unless that happens, people should be able to get by >> by just switching out the -dev packages. > > Are you sure, considering what I wrote above? Yes (depending on what you mean) because the -dev package on a Debian system is the one that contains the .so links, so it dictates which library you'll get when you say -lfoo if there's more than one candidate available. It won't help with your /usr/lib vs /usr/local/lib problem, though. Putting the major number in the library name is how you'd have to fix that. Note that if you wanted (as you suggested above) to allow two micro revisions to be installed in parallel for debugging, we'd have to go so far as to put the full version into the library name, i.e. libguile-12.0.1.so or similar, and I would argue fairly strongly against that. With the full version in the library name, all apps compiled against guile would have to be recompiled when we make *any* guile release, even just a micro revision. It's possible you could avoid that with symlink tricks or similar, but I'd be much more comfortable, if we do anything, with just putting the soname in the library name, and not planning to support parallel installs of micro revisions. Of course I don't actually have a good answer, other than "remove the .so symlinks" (i.e. the -dev pkg on a debian system) to the question of how on any given platform you can actually test/develop a minor guile revision that's different from the one in /usr/lib when you also have to use other foo-config tools that might insert -L/usr/lib into random places on the gcc command line, but this is not a problem specific to guile. It's a broader foo-config/unix-model problem. pkg-config may be able to help here, and gcc could fix the problem if it supported --push-flags and --pop-flags args, but AFAIK neither fix is available yet. We might be able to solve this problem by putting all our libs into /usr/lib/guile/VERSION/ so that you have to specify a -L flag to get anything, but then you've got the ld.so.conf problem, and I agree with Marius that we're probably better off sticking with the normal unix mechanisms and perhaps trying to help come up with a better answer "upstream" if possible. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel