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: packaging the add-on libs... Date: Fri, 11 Oct 2002 10:59:53 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87zntl0xvq.fsf@raven.i.defaultvalue.org> References: <87vg4aevgx.fsf@raven.i.defaultvalue.org> <20021010071246.GA29109@www> <87lm56co8t.fsf@raven.i.defaultvalue.org> <20021011094150.GA3235@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034352365 32376 127.0.0.1 (11 Oct 2002 16:06:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2002 16:06:05 +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 1802Id-0008Pt-01 for ; Fri, 11 Oct 2002 18:06:03 +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 1802Ih-00056z-00; Fri, 11 Oct 2002 12:06:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1802Hp-0004iO-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 12:05:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1802Hn-0004hx-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 12:05:12 -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 1802Ch-00032R-00 for guile-devel@gnu.org; Fri, 11 Oct 2002 11:59:55 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id C22EC17EA; Fri, 11 Oct 2002 10:59:53 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 9C80099D; Fri, 11 Oct 2002 10:59:53 -0500 (CDT) Original-To: tomas@fabula.de In-Reply-To: <20021011094150.GA3235@www> (tomas@fabula.de's message of "Fri, 11 Oct 2002 11:41:50 +0200") Original-Lines: 69 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) 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:1527 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1527 tomas@fabula.de writes: > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy > then and still feel uneasy abut it (see below). Well FWIW, I did some experimentation, and at least on debian systems, during the process of re-building/uploading which would happen every time we release a new major version of libguile, I determined that you are likely to end up with cross-version-links. In my example (imagine libbase is libguile): $ ldd .libs/some-app-2 libuses-base-foo2.so.2 => not found libbase2.so.2 => not found libuses-base-bar.so.1 => not found libbase1.so.1 => not found libc.so.6 => /lib/libc.so.6 (0x40027000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Note that in the expirimental tree, some-app-2 was only linked via libtool against libuses-base-bar and libuses-base-foo2, the two libbase links were pulled in because uses-base-foo2 and uses-base-bar were originally linked against two different versions of libbase. I don't know if how this would work on other platforms, but what's interesting is that at runtime, it appears that the loader resolves any duplicate symbols in favor of the first library listed on the libtool link line. In this case, even though libuses-base-foo2 was linked against libbase2, when it calls libbase_init, it prints the message I put in libbase1's libbase_init. There are no linkage warnings. libuses-base-bar was listed first on the libtool link line, and if I reverse that so that libuses-base-foo2 comes first, then we see the messages from libbase2. In some sense, this could be seen as a good thing, and would hide most problems, i.e. even though you have dual linkage, you always get the symbols from just one version of the libs, but in reality I believe it's a potential disaster since (for example) libuses-base-foo2 was built using libbase2's headers, and libuses-base-bar was built using libbase1's headers. This means that one of them is going to be operating on libbase data structures with the wrong set of macros. Another potential problems comes if libbase2 adds new functions or deletes old ones, then depending on whether libbase2 or libbase1 takes precedence in the "dual link", you'll have some functions from one version of libbase and some from another. > Yes, kind of. Only that I'd substitute ``that aren't supposed to be > directly linkable by'' for ``that have to go with guile to be linked > by...'' > > In other words, if you need guile in conjunction with libfoo, then > libfoo has no business in /usr/lib or /usr/local/lib -- but rather > in /usr/lib/guile/1.6/ (or something like that). IMHO, of course. The main problem with this is that any apps or libs linked against these "add-on" libs will have to do something special to access the libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc. and as we've discussed, there are some definite issues with doing that portably, and in a way that doesn't have the potential to interact badly with other libs that might do the same thing, so we'd have to be cautious when considering this approach. For libs no-one's ever allowed to link directly to, there's no problem. -- 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel