Ensuring symbol resolution order at runtime

["Kevin P. Fleming" <kpfleming at digium dot com>]

(please keep me in the CC list, as I'm not subscribed. thanks)

I'll ask this question in the context of 'modern' Linux (Ubuntu 11.10, 
for example) using ELF binaries and current binutils, but I'm interested 
in knowing whether the behavior I desire, if it is in fact how the 
static/dynamic linkers operate, is specified by any standards, or is 
just 'common practice'.

Scenario 1: An executable is being linked, and the linker is provided 
the names of two static libraries. Both of those libraries export a 
symbol named "foo", and one of the objects being linked into the 
executable refers to that symbol.

In this situation, it is understood that the linker will choose a symbol 
"foo" to satisfy the reference from the *first* library specified in the 
linker's arguments that provides a symbol "foo".

Scenario 2: An executable is being linked, and the static linker is 
provided the names of two shared libraries. Both of those libraries 
export a symbol named "foo", and one of the objects being linked into 
the executable refers to that symbol.

In this situation, it is understood that the static linker will locate a 
symbol "foo" to satisfy the reference from the *first* library specified 
in the linker's arguments that provides a symbol "foo". This is fine. 
However, at runtime, when the dynamic linker has the responsibility for 
loading these shared libraries into the process and resolving symbols, 
is there any guarantee that the the *same* "foo" will be chosen by the 
dynamic linker?

Scenario 3: An executable is being linked, and the static linker is 
provided the name of a shared library. That shared library contains a 
reference to another shared library. Both of those libraries export a 
symbol named "foo", and one of the objects being linked into the 
executable refers to that symbol.

In this situation, the static linker only has the symbol "foo" from the 
first library available to satisfy the reference, because it was not 
made explicitly aware of the second library that also provides "foo". At 
runtime, it seems reasonable to assume that the dynamic linker will load 
the first shared library into the process before the second shared 
library, and *should* resolve symbol references from the executable into 
that library before loading the second shared library into the process.

I'm trying to work on a problem related to multiple shared libraries 
linking to libssl.so (from OpenSSL), and need to come up with a way to 
ensure that only *one* library calls the initialization functions from 
libssl, without requiring any cooperating behavior from the other 
libraries that would normally do it as well. My approach so far has been 
to 'mask' the real functions from libssl.so in another shared library 
that is loaded *first* into the process, thereby ensuring that no matter 
what libraries are loaded into the process later, they will not be able 
to gain access to the underlying functions from libssl.so (other than 
via exploiting dlsym() to do so explicitly).

So, is this approach reasonable, and if so, is it backed up by standards 
or other documents that prescribe the linker's behavior for these 
scenarios? I'm really not keen on relying on any assumptions about the 
dynamic linker's behavior (other than that it will follow the relevant 
standards if it claims to do so).

Thanks in advance for any light you can shed on this :-)

--
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