From: "Kevin P. Fleming" <kpfleming@digium.com>
To: Cary Coutant <ccoutant@google.com>
Cc: binutils@sourceware.org
Subject: Re: Ensuring symbol resolution order at runtime
Date: Fri, 20 Jan 2012 22:47:00 -0000 [thread overview]
Message-ID: <4F19EF05.7020104@digium.com> (raw)
In-Reply-To: <CAHACq4oxqpxCAtCdjo3MFcGKMBkScokb1wiZHCAmTuDoahKbQw@mail.gmail.com>
On 01/20/2012 03:52 PM, Cary Coutant wrote:
> As long as the runtime loader sees the same libraries that the linker
> saw, yes, there is a guarantee. However, if lib1.so is replaced with a
> library that does not define "foo", then the dynamic loader will bind
> "foo" to the definition in lib2.so without any complaint.
So, to be as specific as I can, not only will the runtime loader see
those same libraries, but it will look at them in the *same order* that
the static linker did (presumably because the static linker will list
them in the linked executable in the order it processed them, and the
dynamic linker follows that order).
> I'd think a better approach would be to use a static variable in the
> initialization function to protect it from being called twice. Even
> better would be to have libssl's initialization functions actually
> marked as initialization functions so that they run automatically when
> the library is loaded.
No argument here; unfortunately the maintainers of OpenSSL have not seen
fit to do that, even though this problem has been known about for quite
some time. We are not the first project to have to work around the
problem in our own code, and even other projects that use OpenSSL and
produce their own libraries for consumption (PostgreSQL, for example)
have made accommodations in their libraries to allow the eventual
application using the combined libraries to be able to avoid this
complication. Unfortunately not every library that uses OpenSSL has made
these accommodations, so we need a 'belt and suspenders' approach that
we can rely on.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
next prev parent reply other threads:[~2012-01-20 22:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 19:34 Kevin P. Fleming
2012-01-20 21:52 ` Cary Coutant
2012-01-20 22:47 ` Kevin P. Fleming [this message]
2012-01-20 22:57 ` Cary Coutant
2012-01-20 23:01 ` Kevin P. Fleming
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F19EF05.7020104@digium.com \
--to=kpfleming@digium.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@google.com \
/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).