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