unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue.org>
Subject: Perhaps we can (and should) just detect dangerous linkages...
Date: Sun, 13 Oct 2002 12:33:17 -0500	[thread overview]
Message-ID: <87n0pimeg2.fsf@raven.i.defaultvalue.org> (raw)


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


             reply	other threads:[~2002-10-13 17:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-13 17:33 Rob Browning [this message]
2002-10-13 19:05 ` Perhaps we can (and should) just detect dangerous linkages Neil Jerram
2002-10-13 19:58   ` Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87n0pimeg2.fsf@raven.i.defaultvalue.org \
    --to=rlb@defaultvalue.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).