Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Dynamic loader taking function from wrong lib

Status
Not open for further replies.

rimono

Programmer
Nov 11, 2007
8
IL
Hi,

I have two dynamically loaded libraries (shared objects), both of which include functions of the same name - foo. When I call 'foo' from libA, it takes it from libB, although it is implemented in libA as well. Since we need the function to be called from libA, we tried linking it with the flag -bSymbolic, to no avail. It still called the function from libB.

Specifics: Working on HP 11.23, compiling with HP gdb 5.7.4.

Background: In this case libA is an ODBC driver we've written. libB is the unixODBC driver manager. The way these works is that in our driver we implement a set of SQLxxx functions, which have the same names as the set of functions in the driver manager. When the driver manager loads our ODBC driver, it knows to call the SQLxxx functions from our driver. Our problem is in a case where we call our own SQLxxx function from within our own driver, and it calls the function from the driver manager instead!

Ideas?

Thanks.
 
What happens if you change the order of linking i.e.

-lA -lB
 
What I didn't mention is that libB loads libA dynamically at runtime.
We used the -Bsymbolic flag when we linked libA from the separate objects. From the documentation it seems that -Bsymbolic should have given us what we want, by forcing libA to use its own functions, but it didn't change the behavior at runtime.
 
By load dynamically do you mean it does a dlopen etc.
 
What you're talking about is what is called private protected in Java i.e. public within the library but private outside the library. Don't really know any way around it other than, if you have access to the source code, putting it in a different namespace.
 
Problem resolution – for anyone interested.
The problem was finally solved by -Bsymbolic, but it was in a roundabout way.
We are working on HP and when we ran into the problem we were compiling with gcc. We tried adding –Bsymbolic to the gcc command but it didn’t help. We then tried adding –W1,Bsymbolic in order to pass the option to the linker, but this didn’t help either.
Now we have moved to compile with HP’s native aCC, for reasons that are unrelated to this problem. With aCC when we gave it –W1,Bsymbolic the library’s symbols were finally taken locally.

 
-B seems to do different things on different machines/linkers. We had a some problem using -B with SunOS, AIX and HPUX but that was about 9 years ago and I can't remember what the problem or solution was.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top