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: Release now? Date: Tue, 25 Feb 2003 12:38:20 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87of50tdcz.fsf@raven.i.defaultvalue.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046199863 21837 80.91.224.249 (25 Feb 2003 19:04:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2003 19:04:23 +0000 (UTC) Cc: Marius Vollmer 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 18nkNI-0005ff-00 for ; Tue, 25 Feb 2003 20:04:20 +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 18nkH7-0007rE-00 for guile-devel@m.gmane.org; Tue, 25 Feb 2003 13:57:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nkDD-0006jb-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 13:53:55 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nkAh-0006Fd-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 13:51:20 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18njyC-0002YS-00 for guile-devel@gnu.org; Tue, 25 Feb 2003 13:38:24 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 918FF13888; Tue, 25 Feb 2003 12:38:20 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 65029D0F87; Tue, 25 Feb 2003 12:38:20 -0600 (CST) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "25 Feb 2003 11:08:44 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: guile-devel@gnu.org Original-cc: Mikael Djurfeldt 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:1971 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1971 Greg Troxel writes: > But, running 'pkg-config --use-version 1.6' should be no different > than guile16-config, except that it's easier to write configure.in > fragments. It does mean we get to sidestep the issue about which > guile-config is 'primary' and which has a version number. But I'm > not sure that's a huge issue - the latest can be primary and the > others have the number. Or you can do something like Debian's update-alternatives -- have a priority system, but allow for the local maintainer to override... FWIW, as far as I can tell, the only way we can allow compilation for multiple versions of guile is if we don't put the libs into /usr/lib with the other libraries. Either that, or we have to put our major version number into the library name. In fact we wouldn't be able to put *any* libguile.so into /usr/lib, otherwise *any* other package's foo-config script that put a -L/usr/lib on the gcc command line could cause us to get the wrong one, even if the gcc command line also contained the output of an invocation of guile-X.Y-config somewhere. Another consideration (and perhaps everyone is still aware of) is that of -rpath. There are many who are opposed to it, and without it, you don't really have any way to put guile's libs anywhere but /usr/lib or similar... Hmm, now that I think about it, I wonder if systems could handle just having the .so links off in a subdir, i.e. put libguile.so in /usr/lib/guile/VERSION, but put the actual libguile libs in /usr/lib. This might avoid the need for an -rpath, LD_LIBRARY_PATH, or any changes to ld.so.conf, but still allow specifying a particular guile with -L/usr/lib/guile/VERSION. Hmm... Thoughts? > The NetBSD pkgsrc approach means that when one compiles guile-gtk, > for instance, one could put the 1.4-linked version in > /usr/pkg/guile/1.4 and the 1.6 version in /usr/pkg. Do you really > mean pure Scheme code, or stuff with dynlibs? I would think that > pure Scheme code could feature-test and cope - is this really an > issue? Personally I feel like it is. To me it seems like just as much an issue as it is for binary shared libraries. A module presents an interface, and that interface may change over time. So the client should have some way to ask for a particular "version" of that interface i.e. (use-modules (postgresql-fancy #:interface 3)). Of course, others may differ and feel like we should just leave this up to the author and client to come up with their own scheme, i.e. checking version number, defined?, etc. Though note that I'm not sure we've settled the future of some of the features like defined?. I'd tend to lean towards having a standard strategy like #:interface or maybe #:version for people to use. They can always ignore it and invent their own custom strategies using (use-modules (foo)) if they want. I'm open to being convinced otherwise, though. > But, this all points out the really serious extended consequences of > not maintaining _compile-time_ backwards compatibility. I'm not > (personally) at all worried about running old binaries with newer > guile libraries. The issue is whether programs that compile against > guile can just work when the system's base guile version is > upgraded. Perhaps I'm misunderstanding. If the soname hasn't changed, then you should be fine. If it has, then you have to recompile... Also, unless we can *prove* that nothing has changed in a way that would break backward compatibility, we have to change the soname with each major release. Also I guess we need to be clear what the C lib sonames mean. Do they also reflect the indirect "API" available from ice-9 via scm_c_eval? For example, if we had a function in ice-9 called (get-blarg) that returned `(,foo . ,bar), and we change it so that it returns `(,bar . ,foo), then do we have to change the libguile version number since since C code could access this via scm_c_eval? Perhaps, perhaps not, but I think we should figure this out and make a clear statement in the docs. > We've seen a lot of pain (and non-upgrading of guile in major > distributions) recently. As far as I can tell, this is always going to be true to some extent, though we should do our best to minimize it. I've seen it happen for perl and python regularly, and I'd expect our situation to be worse (and it is) because of our unique requirement that users be able to link directly to our libraries from C, and that of course leads to libs linked to libs linked to guile and the whole "indirect linkage to two versions of libguile" problem. > So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good, If you mean drop-in as in "just requires a recompile of things linked against it", then I suspect that's quite possible. If you mean "doesn't even require recompile", then I at least somewhat doubt it. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel