DBD::Oracle with Oracle 9i requires LD_LIBRARY_PATH on HP-UX

[Ryan Novosielski]

Hi!

I recently built DBD::Oracle 1.21 and 1.22 on an HP-UX 64bit box.

Apparently, even though the outpu +t of chatr would lead me to believe the PATH is embedded:

/opt/perl_64/lib/site_perl/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/DBD/Oracle/Oracle.sl:
64-bit ELF shared library
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /opt/oracle/product/9.2.0/lib:/opt/oracle/product/9.2.0/rdbms/lib
shared library list:
libclntsh.sl.9.0
libm.2
libqsmashr.sl
shared library mapped private disabled
shared vtable support disabled
explicit unloading enabled
linkage table protection disabled
segments:
index type address flags size
5 text 4000000000000000 z---c- D (default)
6 data 8000000100000000 ---m-- D (default)
static branch prediction disabled
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr references disabled

...it appears as if the machine never looks in /opt/oracle/product/9.2.0/lib . I'm not too too too +familiar with HP-UX library handling, but this seems odd to me. This does not appear to be the case with Oracle 10g. Does anyone know what's going on here? Here's the output of 'tusc' when things are taking place:

open("/b/s014/lib//libwtc9.sl", O_RDONLY|O_LARGEFILE, 0) ................................................................................ ERR#2
ENOENT
open("/b/s014/rdbms/lib//libwtc9.sl", O_RDONLY|O_LARGEFILE, 0) .......................................................................... ERR#2
ENOENT
open("/lib/pa20_64/libwtc9.sl", O_RDONLY|O_LARGEFILE, 0) ................................................................................ ERR#2
ENOENT
open("/usr/lib/pa20_64/libwtc9.sl", O_RDONLY|O_LARGEFILE, 0) ............................................................................ ERR#2
ENOENT

...as you can see, it never checks the right place. Thanks in advance for any advice.

[Dennis Handly]

>it appears as if the machine never looks in /opt/oracle/product/9.2.0/lib

It will only look here for the dependent shlibs of Oracle.sl: libclntsh.sl.9.0 libqsmashr.sl

Not libwtc9.sl.

[Ryan Novosielski]

Of course! Duh.

Now, is there any way to make sure that that PATH is checked without setting LD_LIBRARY_PATH system-wide (or to make sure that that library is also looked for there?). Or am I basically stuck setting LD_LIBRARY_PATH? This doesn't seem to be a problem on Oracle 10g, which is good.

I'm not a programmer really -- would adding -llibwtc or something like that cause it to be referenced as well?

[Dennis Handly]

>is there any way to make sure that that path is checked without setting LD_LIBRARY_PATH system-wide

Yes, you have to figure out which load module needs libwtc9.sl and relink with +b path.

>would adding -llibwtc (or something like that) cause it to be referenced as well?

(That would be -lwtc9.)
Probably not. There could be two different libwtc, one here and one where it doesn't know where it is.

[Ryan Novosielski]

Now, it's odd, as it appears as if that is already happening:

/usr/bin/ld +b"/opt/oracle/product/9.2.0/lib:/opt/oracle/product/9.2.0/rdbms/lib" -b +vnocompatwarnings -L/lib/pa20_64 Oracle.o dbdimp.o oci8.o -L/opt/oracle/product/9.2.0/rdbms/lib/ -L/opt/oracle/product/9.2.0/lib/ -lclntsh `cat /opt/oracle/product/9.2.0/lib/ldflags` -lm -lqsmashr -o blib/arch/auto/DBD/Oracle/Oracle.sl

...doesn't that initial +b look like that is being taken care of, or is there a syntax problem there that I'm not catching?

Only thing other that is of interest is that the ldd -v output is odd for that one library:

ldd -v /opt/perl_64/lib/site_perl/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/DBD/Oracle/Oracle.sl

find library=libclntsh.sl.9.0; required by /opt/perl_64/lib/site_perl/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/DBD/Oracle/Oracle.sl
libclntsh.sl.9.0 => /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0

find library=libm.2; required by /opt/perl_64/lib/site_perl/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/DBD/Oracle/Oracle.sl
libm.2 => /lib/pa20_64/libm.2

find library=libqsmashr.sl; required by /opt/perl_64/lib/site_perl/5.8.8/PA-RISC2.0-thread-multi-LP64/auto/DBD/Oracle/Oracle.sl
libqsmashr.sl => /opt/oracle/product/9.2.0/lib/libqsmashr.sl

find library=libwtc9.sl; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libwtc9.sl => /opt/oracle/product/9.2.0/lib/libwtc9.sl

find library=librt.2; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
librt.2 => /lib/pa20_64/librt.2

find library=libpthread.1; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libpthread.1 => /lib/pa20_64/libpthread.1

find library=libnss_dns.1; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libnss_dns.1 => /lib/pa20_64/libnss_dns.1

find library=libdl.1; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libdl.1 => /lib/pa20_64/libdl.1

find library=libc.2; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libc.2 => /lib/pa20_64/libc.2

find library=libcl.2; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libcl.2 => /lib/pa20_64/libcl.2

find library=libwtc9.sl; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
/opt/oracle/product/9.2.0/lib/libwtc9.sl => /opt/oracle/product/9.2.0/lib/libwtc9.sl

find library=libcl.2; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libcl.2 => /lib/pa20_64/libcl.2

find library=librt.2; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
librt.2 => /lib/pa20_64/librt.2

find library=libpthread.1; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libpthread.1 => /lib/pa20_64/libpthread.1

find library=libnss_dns.1; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libnss_dns.1 => /lib/pa20_64/libnss_dns.1

find library=libdl.1; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libdl.1 => /lib/pa20_64/libdl.1

find library=libm.2; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libm.2 => /lib/pa20_64/libm.2

find library=libc.2; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
libc.2 => /lib/pa20_64/libc.2

find library=libdl.1; required by /lib/pa20_64/librt.2
libdl.1 => /usr/lib/pa20_64/libdl.1

find library=libdl.1; required by /lib/pa20_64/libcl.2
libdl.1 => /usr/lib/pa20_64/libdl.1

What I find suspicious about this is that libclntsh calls libwtc9 as just libwtc9.sl which is then resolved to a location. The other calls libwtc9.sl in its full path, which then is also resolved to the right place.

A little embarrassing to have been doing this this long and not really know too much about linking, but it's always "just worked" before.

[Dennis Handly]

>doesn't that initial +b look like that is being taken care of, or is there a syntax problem there that I'm not catching?

I thought you understood when you said "Duh"?
The +b for Oracle.sl has no affect on the shlib that has libwtc9.sl for a dependency.

And +b doesn't apply recursively to libclntsh.sl.9.0. Though you show that works, so there may be another shlib you need to look at.

>The other calls libwtc9.sl in its full path, which then is also resolved to the right place.

"The other" what? Where is the one that is failing? I would need to see the tusc output right before your first one.

[Ryan Novosielski]

>I thought you understood when you said "Duh"?
>The +b for Oracle.sl has no affect on the >shlib that has libwtc9.sl for a dependency.

OK, I thought +b did have an effect on the dependency and that it was another flag that did not.

I think what threw me is this:

>Yes, you have to figure out which load >module needs libwtc9.sl and relink with +b >path

I guess what you mean is if it happens to be library that came with Oracle, this is not possible as I'd have to re-link THAT library which is something I doubt is possible.

>And +b doesn't apply recursively to >libclntsh.sl.9.0. Though you show that >works, so there may be another shlib you >need to look at.

Correct me if I'm wrong, but from the output below it looks like it's libqsmashr.sl

>>The other calls libwtc9.sl in its full >>path, which then is also resolved to the >>right place.
>
>"The other" what? Where is the one that is >failing? I would need to see the tusc >output right before your first one.

What I meant by this was the difference between these two lines:

find library=libwtc9.sl; required by /opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
libwtc9.sl => /opt/oracle/product/9.2.0/lib/libwtc9.sl

find library=libwtc9.sl; required by /opt/oracle/product/9.2.0/lib/libqsmashr.sl
/opt/oracle/product/9.2.0/lib/libwtc9.sl => /opt/oracle/product/9.2.0/lib/libwtc9.sl

I'm not sure if there's anything significant to that difference.

I attached a full output of tusc. If I'm reading it right, it is libqsmashr that is calling the libwtc9, which I guess may mean that I'm stuck with setting that environment variable unless there is anyway to force the compilation of this Oracle.sl (from DBD::Oracle) to be aware of that library, not just rely on the dependencies to know where it is.

I didn't perform the Oracle install so I don't know if there's anything wrong with it.

Thanks again for all of your help.

[Dennis Handly]

>ldd -v .../Oracle.sl

Was the above ldd also done with SHLIB_PATH or LD_LIBRARY_PATH set?

What is the output of "chatr .../Oracle.sl"? And for libqsmashr.sl.

>I thought +b did have an effect on the dependency

Yes, to find the dependency. But not for dependencies of that dependency.

>that it was another flag that did not.

SHLIB_PATH would only be honored if enabled at each level.

>but from the output below it looks like it's libqsmashr.sl

It looks like it.

>it is libqsmashr that is calling the libwtc9, which I guess may mean that I'm stuck with setting that environment variable

Yes. But looking at "chatr libqsmashr" will tell us for sure.