From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29810 invoked by alias); 20 Aug 2008 19:31:35 -0000 Received: (qmail 29792 invoked by uid 22791); 20 Aug 2008 19:31:32 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Aug 2008 19:30:37 +0000 Received: by ug-out-1314.google.com with SMTP id t39so783619ugd.10 for ; Wed, 20 Aug 2008 12:30:34 -0700 (PDT) Received: by 10.187.222.11 with SMTP id z11mr35704faq.60.1219260634296; Wed, 20 Aug 2008 12:30:34 -0700 (PDT) Received: by 10.187.203.18 with HTTP; Wed, 20 Aug 2008 12:30:34 -0700 (PDT) Message-ID: Date: Wed, 20 Aug 2008 19:36:00 -0000 From: Arindam To: "Ian Lance Taylor" Subject: Re: Restricting symbol binding within shared object Cc: gcc-help@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00204.txt.bz2 On 8/19/08, Ian Lance Taylor wrote: > Arindam writes: > > > I have two shared libraries linked to an executable. The executable > > calls two functions - say bar1() in one shared lib and bar2() in > > another. It so happens that both bar1 and bar2 internally call a > > function say foo(). There is a different version of foo defined in > > each shared object with same signature but different internal > > implementation. It so happens that when both shared libs are linked to > > my executable, both bar1 and bar2's calls resolve to the foo defined > > in shared object 1. I am trying to figure out a way to resolve each > > call "locally" within the shared object. I tried the -Bsymbolic switch > > for the linker but it did not work - perhaps because this is C++ code, > > although the functions in question are declared with C linkage (extern > > "C"). > > -Bsymbolic should have worked. Note that you have to use it when > linking the shared libraries. It actually does work. My mistake - I used -symbolic with g++ instead, expecting it to translate to -Bsymbolic for the linker. I later used -Wl,-Bsymbolic and that worked for me. > > With a newer version of gcc you can use visibility attributes. That > is probably your best approach here. > > http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#Function-Attributes > > search for > visibility ("visibility_type") > Cool ... so this mimics the Windows __declspec(dllexport) kind of declarations. I know that newer versions of Sun Studio have essentially the same functionality (albeit with a less obnoxious syntax). I need to figure out if aCC on HP-UX has something similar too. Is this a new thing on ELF format? - Arindam