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: add-on lib versioning (concrete example g-wrap) -- what to do? Date: Thu, 12 Dec 2002 14:25:46 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87d6o7vvat.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 1039725875 26832 80.91.224.249 (12 Dec 2002 20:44:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2002 20:44:35 +0000 (UTC) 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 18MaC9-0006yd-00 for ; Thu, 12 Dec 2002 21:44:33 +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 18MaCC-0005Ac-0C for guile-devel@m.gmane.org; Thu, 12 Dec 2002 15:44:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18Ma1u-0001OC-00 for guile-devel@gnu.org; Thu, 12 Dec 2002 15:33:58 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18MZvH-0007Q4-00 for guile-devel@gnu.org; Thu, 12 Dec 2002 15:27:10 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18MZu1-0006WD-00 for guile-devel@gnu.org; Thu, 12 Dec 2002 15:25:49 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 5AE42F69E for ; Thu, 12 Dec 2002 14:25:47 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 123EABBE19; Thu, 12 Dec 2002 14:25:46 -0600 (CST) Original-To: guile-devel@gnu.org User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) 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:1823 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1823 So a concrete case for our add-on library policy which unless I'm overlooking something obvious, raises some important questions about our current position (which I fear may be untenable, but I'd like a sanity check). There's a broader issue here, but practically speaking, the question I have to answer *right now* with respect to g-wrap is pretty straightforward. I have to settle on versions for the libraries in the latest release of g-wrap. There are a number of libraries, but lets consider just one, libgwrap-glib.so, which depends on both libglib and libguile, and it can be built against either guile1.4 or guile1.6 (and perhaps multiple major releases of glib, but that's not relevant here). So how do I pick the soname for this library? Say I pick 1 and then you (the user) configures and builds gwrap against guile 1.4, and ends up with libgwrap-glib.so.1. OK, so presume other apps are then built against guile 1.4 and gwrap and installed on the system. Now say you install guile 1.6 and rebuild g-wrap against 1.6, which again produces libgwrap-glib.so.1, but this one is linked against libguile from 1.6. Now you have a file conflict. You can't install the new libgwrap-glib.so.1 without breaking any apps or libs on your system that are still linked against and using the old libgwrap-glib.so.1 and the old libguile9. So what to do? To fix this you need to end up with two copies of libgwrap-glib either with different names, or different sonames. However in discussions in the past, we've rejected the first solution -- the idea of embedding the guile version in the library name. i.e. libguile1.6-gwrap-glib. So that just leaves the different soname approach (i.e. compile the guile 1.4 and guile 1.6 linked versions of libgwrap-glib with different sonames), but how do we portably handle that? Do I pick the soname at configure time, somehow based on the version of libguile that libgwrap-glib is about to link against? Do all add-on libs have to do this? If so, then all add-on libs are going to have to follow the same restrictions that we've agreed to for internal guile libs, which means that (1) they may *not* change their major soname during a guile stable series, and (2) they *must* change their major soname whenever guile has a new major release and consequently changes its major soname. i.e. all add-on libs will have to remain in lock-step with guile library version-wise. Perhaps I'm wrong, but this seems like it might be restrictive enough to significantly stifle development, and it isn't really much different than just requiring the add-on libs to put the guile version number in their name -- which makes the rule explicit while still leaving the add-on libs the flexibility to change their major-soname if they need to. Note I'm not necessarily suggesting we should switch to the policy of embedding the guile version in the add-on lib name, just pointing out that of the above two choices, it accomplishes roughly the same thing and is perhaps clearer since it's more explicit. (Of course you could just say that you can't have two copies of gwrap on the same system, but even so, that still leaves open the question of how the soname should be chosen -- since even across machines of the same arch, the same soname is supposed to indicate ABI compatibility.) All that said, I'm not quite sure what a better solution would be[1]. I'm just still somewhat worried that guile might be painting itself into a corner here, though I'd love to be proven wrong. FWIW I'd also like to point out that this is definitely a point against guile in the broader "which language should I use for X project" arena. I've actually seen it have a negative impact. I also suspect that unless we address this, it's may be difficult for our outside guile-core "add-on" base to grow and maintain much long-term stability. [1] The only contenders I can think ATM of are - put the guile version in the add-on lib name. - use a /usr/lib/guile/VERSION/ subdir for add on libs and just figure out and deal with the -L/LD_LIBRARY_PATH/rpath issues. - more radically, drop the idea that people will directly link via gcc/ld against guile libs, and require some kind of run-time dlopen/dlsym/function-pointer-patchup initialization. i.e. scm_make_u8_vector = scm_lt_dlsym (srfi_4_lib, "scm_make_u8_vector"); or similar. The first two are probably the least intrusive if we can work out the details. Thoughts? -- 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