problem with linkage of so under RHEL3

[Bill Medland]

Guys

(I'll be looking into it tomorrow but I thought I'd see if anyone already 
knows)

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

The application can also be built under Linux, as can "That Dll" and link 
directly to unixODBC.  Under that configuration it works fine.

In all the messing about with the threading etc can anyone think immediately 
of where we might have messed up the linking?

(Wine is rather old - cvs compile of about 20040408)

[Bill Medland]

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.

[Alexandre Julliard]

Bill Medland  writes:
> So for future reference is there an easy way to see what functions a so 
> provides that don't show up in nm?

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

Just a wild guess, but you could try adding RTLD_GLOBAL to the dlopen
call where Wine opens libodbc.so.

[Bill Medland]

On June 25, 2004 12:59 pm, Alexandre Julliard wrote:
> Bill Medland  writes:
> > So for future reference is there an easy way to see what functions a so
> > provides that don't show up in nm?
>
> Try nm -D.

Thanks.
> > Then I guess the question will be a matter of why the dlopen doesn't see
> > the existing functions when underneath Wine.
>
> Just a wild guess, but you could try adding RTLD_GLOBAL to the dlopen
> call where Wine opens libodbc.so.

Yep.  That solves the link problem.  I'll submit it later.  Thanks.

(Now to figure out why it doesn't run.)