From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13151 invoked by alias); 20 Jan 2012 19:34:27 -0000 Received: (qmail 12605 invoked by uid 22791); 20 Jan 2012 19:34:26 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_KP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.digium.com (HELO mail.digium.com) (216.207.245.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jan 2012 19:34:10 +0000 Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RoKDx-0007Wj-7B for binutils@sourceware.org; Fri, 20 Jan 2012 13:34:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 33D7FD8004 for ; Fri, 20 Jan 2012 13:34:09 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX0heJIYuXFK for ; Fri, 20 Jan 2012 13:34:08 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id C6528D8002 for ; Fri, 20 Jan 2012 13:34:08 -0600 (CST) Message-ID: <4F19C1B0.8080601@digium.com> Date: Fri, 20 Jan 2012 19:34:00 -0000 From: "Kevin P. Fleming" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: binutils@sourceware.org Subject: Ensuring symbol resolution order at runtime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00212.txt.bz2 (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