On 8/19/08, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > Arindam <arindam.mukerjee@xxxxxxxxx> 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
