From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10373 invoked by alias); 20 Jan 2012 22:47:50 -0000 Received: (qmail 10362 invoked by uid 22791); 20 Jan 2012 22:47:48 -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 22:47:35 +0000 Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RoNF8-0001uD-Sg; Fri, 20 Jan 2012 16:47:34 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id DA2FBD8004; Fri, 20 Jan 2012 16:47:34 -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 ggeA9VA5IXvT; Fri, 20 Jan 2012 16:47:34 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 75983D8002; Fri, 20 Jan 2012 16:47:34 -0600 (CST) Message-ID: <4F19EF05.7020104@digium.com> Date: Fri, 20 Jan 2012 22:47: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: Cary Coutant CC: binutils@sourceware.org Subject: Re: Ensuring symbol resolution order at runtime References: <4F19C1B0.8080601@digium.com> In-Reply-To: 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/msg00215.txt.bz2 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