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: Perhaps we can (and should) just detect dangerous linkages... Date: Sun, 13 Oct 2002 12:33:17 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87n0pimeg2.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034530486 12403 127.0.0.1 (13 Oct 2002 17:34:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2002 17:34:46 +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 180mdY-0003Ds-00 for ; Sun, 13 Oct 2002 19:34:45 +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 180mcw-0007OD-00; Sun, 13 Oct 2002 13:34:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 180mcF-0007Gt-00 for guile-devel@gnu.org; Sun, 13 Oct 2002 13:33:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 180mcA-0007Fw-00 for guile-devel@gnu.org; Sun, 13 Oct 2002 13:33:22 -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 180mcA-0007FQ-00 for guile-devel@gnu.org; Sun, 13 Oct 2002 13:33:18 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id B19B9EC71 for ; Sun, 13 Oct 2002 12:33:17 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 8DAE218C1; Sun, 13 Oct 2002 12:33:17 -0500 (CDT) Original-To: guile-devel@gnu.org Original-Lines: 63 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:1544 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1544 Feel free to disagree, but after the recent "add-on" lib discussion, it seems to me that the fundamental problem is not specific to guile, and probably isn't one we can fix from the guile side, and though the libguile12-foo approach seems like it would fix the problem with libguile, it wouldn't help the broader unix sub-library versioning problem, and couldn't scale to fix that problem because libguile12-gtk2-gnome3-foo is only for crazy people :> However yesterday I did start to wonder if we might be able to at least *detect* the problem at runtime whenever it involves libguile. If this isn't too hard, then I think it might be worth doing. Detecting dual-libguile linkages should help avoid some fairly confusing runtime errors by aborting before any damage can be done. I haven't quite figured out the details yet, but the general idea would be to arrange it so that anything that compiles against libguile stashes away the major number for that version of libguile (via a #define/macro) at compile time, and then checks that number with a libguile function call at runtime. I've wondered if we might be able to make this automatic somehow, but even if not, it doesn't seem unreasonable to require every library (or app) that uses libguile to call scm_require_version(SCM_MAJOR) before calling any other guile functions. A failed check would cause an abort with a suitable message. A naive implementation should only require a couple of lines of code. I've tested this in my little sub-lib testbed and it seems to work: $ ./some-app-1 init libuses-base-foo1 init libbase1 init libuses-base-bar init libbase1 $ ./some-app-2 init libuses-base-foo2 Required libbase version 2 but found version 1. Aborting. $ ldd .libs/some-app-2 libuses-base-bar.so.1 => not found libbase1.so.1 => not found libuses-base-foo2.so.2 => not found libbase2.so.2 => not found libc.so.6 => /lib/libc.so.6 (0x40028000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) some-app-2 was linked against libuses-base-foo2 which was linked against libbase2 and libuses-base-bar which was linked against libbase1. So when some-app-2 calls libuses_base_foo_init and that in turn calls libbase_require_version(LIBBASE_MAJOR_VERSION), the check fails because at runtime foo is calling the libbase_require_version from libbase1, but passing it the compile-time embedded value for LIBBASE_MAJOR_VERSION from the libbase2 it was compiled against. Thoughts? -- 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