From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: Perhaps we can (and should) just detect dangerous linkages...
Date: Sun, 13 Oct 2002 14:58:37 -0500 [thread overview]
Message-ID: <873cram7pu.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <m3zntitb1e.fsf@laruns.ossau.uklinux.net> (Neil Jerram's message of "13 Oct 2002 20:05:01 +0100")
Neil Jerram <neil@ossau.uklinux.net> writes:
>>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:
>
> Rob> some-app-2 was linked against libuses-base-foo2 which was linked
> Rob> against libbase2 and libuses-base-bar which was linked against
> Rob> libbase1. So when some-app-2 calls libuses_base_foo_init and that in
> Rob> turn calls libbase_require_version(LIBBASE_MAJOR_VERSION), the check
> Rob> fails because at runtime foo is calling the libbase_require_version
> Rob> from libbase1, but passing it the compile-time embedded value for
> Rob> LIBBASE_MAJOR_VERSION from the libbase2 it was compiled against.
>
> When an app like this is run, does the system load and use both
> libbase1 and libbase2, or does it load both but only use one, or what?
Well with my proposed checks, the app would just crater. Without the
checks, see my earlier message(s) for more details, but the summary is
that athough I suspect it depends heavily on the OS (and probably even
on whether or not you're using libtool), on a current Debian/GNU/Linux
system using libtool, if you do nothing, some-app-2 can end up linked
indirectly against both libbase.1 and libbase.2, and at runtime, *all*
libbase symbols in the process image will resolve to one copy of
libbase, the other libbase will be completely shadowed. Which one is
chosen appears to depend on the ordering of libuses-base-foo and
libuses-base-bar in the _LDADD line of some-app-2 -- whichever one is
first wins globally.
Presming that the ordering is such that libbase.2 dominates, I don't
actually know what happens if libbase.2 removes some symbols from the
libbase api. Do the older libbase.1 versions of those symbols then
"show through"? I suppose I could test, but I suspect the answer
would only mean something for the particular system I'm testing...
--
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
prev parent reply other threads:[~2002-10-13 19:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-13 17:33 Perhaps we can (and should) just detect dangerous linkages Rob Browning
2002-10-13 19:05 ` Neil Jerram
2002-10-13 19:58 ` Rob Browning [this message]
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=873cram7pu.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=guile-devel@gnu.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).