problem with linkage of so under RHEL3

Bill Medland billmedland at mercuryspeed.com
Fri Jun 25 12:46:32 CDT 2004


On June 24, 2004 05:46 pm, Bill Medland wrote:
> Guys
>
> Command line application opens a dll using LoadLibrary.
> That Dll links to odbc
> odbc uses unixODBC to link to the new Oracle 10g Beta ODBC client.
> That client so access rather a lot of Oracle libraries
>
> Relocation error occurs
>
> /usr/local/bin/wine-pthread: relocation error:
> /opt/oracle/product/10.1.0/client_1/lib/libsqora.so: undefined symbol:
> SQLGetPrivateProfileString

Can anyone help me on this please.  I am basically constrained by my lack of 
deep knowledge about Linux and would appreciate guidance.  I am quite 
prepared to do my best to help fix the problem with Wine but cannot do it 
alone.

First, can someone explain why the Linux equivalent does work.
unittest links to mylib.so using dlopen (..., RTLD_NOW)
mylib.so is linked to libodbc.so
At the request of mylib via a SQLDriverConnect libodbc.so opens a link to 
$ORACLE_HOME/lib/libsqora.so.  I don't know whether it is RTLD_NOW or 
RTLD_LAZY because it's down in libtools somewhere

Now here is where I get confused.
ldd -r libsqora.so shows 7 unresolved functions, including 
SQLGetPrivateProfileString
It also does not show a dependency on libodbc itself.
SQLGetPrivateProfileString does exist in libodbc.
nm libodbc.so does not show it.
Presumably the link works because since it was the libodbc that linked to 
libsqora.so SQLGetPrivateProfileString was already defined when the dlopen 
occurred.
So for future reference is there an easy way to see what functions a so 
provides that don't show up in nm?

Then I guess the question will be a matter of why the dlopen doesn't see the 
existing functions when underneath Wine.

-- 
Bill Medland
mailto:billmedland at mercuryspeed.com
http://webhome.idirect.com/~kbmed




More information about the wine-devel mailing list