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.