PA-RISC vs ELF-32 with libclntsh.so Oracle lib

[krushna]

Hi,
I am in HP Itanium,
HP-UX iaauto1 B.11.23 U ia64 1357667136

My exe is ELF-32 format,
fred: ELF-32 executable object file - IA64

i used libclntsh.so at compile time. But at run time its asking for libclntsh.sl file.

If i give reference to libclntsh.sl file, it does not work, But if i rename original libclntsh.so to libclntsh.sl it works.

I have tried ldd , its not showing .sl files linked with that.

how to resolve the issue???

-krushna

[Duncan Edmonstone]

Maybe another library you linked with is looking for the .sl library name. Have you run ldd on all the libraries that *are* listed in the ldd output for your executable?

HTH

Duncan

[krushna]

Hi,
While building application, we have given link path to .so file only. So at run time it shd look for .so file. I am wondering why it is looking for .sl file. Again just renaming .so to .sl it works.

logically if both exe and lib are in ELF-32, then at run time it should link to .so file.
As in itanium, ELF-32 shared object lib is .so files.

thanks

[Duncan Edmonstone]

So are you saying that libclntsh.so is the *only* library you link the executable with?

What other libraries does ldd show for your executable.

The point I was trying to make is that libraries can reference other libraries themselves.

HTH

Duncan

[Dennis Handly]

>But if i rename original libclntsh.so to libclntsh.sl it works.

You shouldn't rename the file but you can add a symlink.

>As in Integrity, ELF-32 shared object lib is .so files.

That's the default and the recommended suffix but dld doesn't care what the name is.

>Duncan: Maybe another library you linked with is looking for the .sl library name.

Perhaps another PA process is created?
It would help if the exact error message was given.

[krushna]

Output of ldd command on the executable which we are using.

libtcl8.4.so => /tools/rd/tcl/v8.4.2/lib/libtcl8.4.so
libnsl.so.1 => /usr/lib/hpux32/libnsl.so.1
libstd_v2.so.1 => /usr/lib/hpux32/libstd_v2.so.1
libCsup.so.1 => /usr/lib/hpux32/libCsup.so.1
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
libm.so.1 => /usr/lib/hpux32/libm.so.1
libunwind.so.1 => /usr/lib/hpux32/libunwind.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libm.so.1 => /usr/lib/hpux32/libm.so.1
libxti.so.1 => /usr/lib/hpux32/libxti.so.1
libuca.so.1 => /usr/lib/hpux32/libuca.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1

Below is the runtime error message, when trying to connect to oracle db from the application.

Line:

[Dennis Handly]

>Below is the runtime error message, when trying to connect to oracle db from the application.
Line:

This doesn't look like a dld error message. So it seems that the application must be broken and calling dlopen(3) directly on that wrong spelling of the shlib.

[krushna]

actually we are not using dlopen() in our code. We are using thid ".so" file for dynamic linking only.

-krushna

[Duncan Edmonstone]

Most of those libraries look pretty standard except for libtcl8.4.so

What do you get when you run ldd against that library?

HTH

Duncan

[Dennis Handly]

>actually we are not using dlopen() in our code. We are using this ".so" file for dynamic linking only.

Then you may have to use tusc to see who is trying to open that file.