1820475 Members
3276 Online
109624 Solutions
New Discussion юеВ

Perl DBD::Oracle Failure

 
David Cogley_1
Occasional Advisor

Perl DBD::Oracle Failure

I have installed the ansic compiler. With that, I have installed perl 5.6.1 following the advice of Ramesh Upadhyayula (this forum) and Lincoln A. Baxter (README.hpux). Make test is perfect.

I have installed DBI 1.201. Make test is perfect.

I have attempted to install DBD::Oracle 1.12 to communicate with Oracle 8.1.7 EE installed on the same machine. There are two problems. First, the Makefile has LIBS with many parameter values repeated . This list is 19 lines long in my XWindow. Second, during "make", I get the error "ld: Can't find library: nbeq8." Using "find", I have verified that there is no file containing the characters "nbeq8" in the filename.

Reading Lincoln Baxter's README.hpux, I note "Building a working, dynamically-linked version of the Oracle DBD driver on HPUX (11.0) has been a challenge for many."

I have attached the logfile I generated for the DBD::Oracle build.
12 REPLIES 12
Eric Ladner
Trusted Contributor

Re: Perl DBD::Oracle Failure

The huge number of libs in the make is normal. Even though some are repeated, if you take any out, it won't work.

I have an oracle 8.1.7 install and I did find the libnbeq8.a under $ORACLE_HOME/lib and $ORACLE_HOME/lib64

My guess is that when the protocol adapters were installed, the libs for the bequeath adapter weren't copied in for some reason. I was able to find the files in the install log in the oraInventory log as well, but couldn't figure out what package they were a part of.

Is this on the server or a client machine? My guess is it's on a client machine.
Christopher Caldwell
Honored Contributor

Re: Perl DBD::Oracle Failure

If you use HP's linker, you can deal with the large number of recurring libraries by passing the +n argument which says "to resolve symbols, recurse through the library list until you make one entire pass without resolving any symbols". This directive keeps you from having to figure out library dependencies. I haven't messed with Perl 5.6, but most of the idiosyncrasies with 5.004 were Oracle's odd idea of how things should work.

Once you get the unique list of libraries, chop out the one that's not found, and try your make without that library.

I've also been known to use a
find /u01/~lib -type f | xargs grep symbol_im_looking_for
Christopher Caldwell
Honored Contributor

Re: Perl DBD::Oracle Failure

 
David Cogley_1
Occasional Advisor

Re: Perl DBD::Oracle Failure

I've found libnbeq8.a in /u00/app/oracle/product/8.1.7/lib by executing "find / -name *nbeq8*". Previously, I had not included the "*" before "nbeq8*". Sorry.

libnbeq8.a has 644 permisssions as do the other "*.a" files referenced in the log. Not knowing for certain what to do, I added /u00/app/oracle/product/8.1.7/lib to PATH and to SHLIB_PATH in .profile and executed .profile before I tried rebuilding DBD::Oracle. It failed at the "make" stage with the same error message.

To answer Eric Ladner's question: I am working on the server.

I will now work on Christopher Caldwell's 2 posts. I will let you know what happens.

Thank you!
David Cogley_1
Occasional Advisor

Re: Perl DBD::Oracle Failure

Christopher,

Please, explain exactly where and how I can add the +n flag.

Building DBD modules is not something I've done before. I just want to get the modules built so I can get on with the real job of porting an Sybase/Perl application to Oracle/Perl.

Thanks for your help.

David
Eric Ladner
Trusted Contributor

Re: Perl DBD::Oracle Failure

One thing you could try is to grab that 'ld' command line that fails at the end and put it in a file.

Change the -a shared to -a archive_shared

It might be bombing because there isn't a shared version of libnbeq8

Execute that one command. If it succeeds, run the make again. It should skip over and start where you left off.

If not, edit the Makefile and find that -a shared part and change it in the Makefile.
H.Merijn Brand (procura
Honored Contributor

Re: Perl DBD::Oracle Failure

Or convert the .a to a shared lib (if possible)

# cd /tmp
# mkdir beq8
# cd beq8
# ar x /u00/app/oracle/product/8.1.7/lib/libnbeq8.a
# ld -b -o libnbeq8.sl *.o
#

If this works without warnings, you have a reasonable chance that the objects in the .a are PIC objects (compiled with +z or +Z) and the .sl should work too.

HTH
Enjoy, Have FUN! H.Merijn
David Cogley_1
Occasional Advisor

Re: Perl DBD::Oracle Failure

I implemented Eric Ladner's latest suggestion and seem to have gotten past the nbeq8 problem. Specifically, I ftp'ed the Makefile to a Windows box, edited the Makefile in Word, saved it as a text file and ftp-ed it back to the Unix box. (I used Word because I didn't want to compile vi with LINE_MAX set to a high value.) Then I ran "make" and "make test".

"make test" reports "FAILED tests 4-5".

The first error which shows up is:
t/base............../usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads/libjava.sl

As you might expect if you read the earlier messages in this thread, libjava.sl is present in /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads. Permissions on libjava.sl are 755. Permissions on the native_threads directory are 775. In both cases, the owner is oracle:oinstall.
Christopher Caldwell
Honored Contributor

Re: Perl DBD::Oracle Failure

>Please, explain exactly where and how I can add the +n flag.


1) $ LDFLAGS=+n
2) edit the Makefile produced by perl Makefile.PL and add +n to the LDFLAGS line.

>Building DBD modules is not something I've >done before. I just want to get the modules >built so I can get on with the real job of >porting an Sybase/Perl application to >Oracle/Perl.

Don't we all. Welcome to the show. As Dicky V says, "it's going to be another Maalox masher".

>The first error which shows up is:
>t/base............../usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads/libjava.sl


The crappy thing about this is that you don't even need to think about java for what your doing. Unfortunately, Oracle tends to over complicate things.

Try rebuilding DBD - you need to figure out why Oracle thinks it wants libjava.sl. See if it's listed as a dependency in libclntsh.sl (chatr libclntsh.sl). If it's not (or if you're building a static version of DBD, remove libjava.sl from the Makefile produced by perl Makefile.PL.


I've never been able to build DBD the same way twice, and 99% of that is because Oracle over-complicates makefiles.

David Cogley_1
Occasional Advisor

Re: Perl DBD::Oracle Failure

$ chatr libclntsh.sl.8.0
chatr(error): dl_header_ext.size != sizeof(dl_header_ext). Please update your version of the chatr tool.
libclntsh.sl.8.0:
shared library
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
internal name:
libclntsh.sl.8.0
shared library list:
dynamic /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads/libjava.sl
dynamic /u00/app/oracle/product/8.1.7/lib/libwtc8.sl
dynamic /usr/lib/librt.2
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/libnss_dns.1
dynamic /usr/lib/libdld.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libc.2
dynamic /usr/lib/libcl.2
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: D (default)
instruction page size: D (default)
$


AND, WE FIND THAT THE FILE EXISTS
$ ll /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads/libjava.sl
-rwxr-xr-x 1 oracle oinstall 1601536 Jan 16 10:50 /u00/app/oracle/product/8.1.7/JRE/lib/PA_RISC/native_threads/libjava.sl
$
Christopher Caldwell
Honored Contributor

Re: Perl DBD::Oracle Failure

Okay, that output says libjava.sl is built into libclntsh.sl. We also know that libjava.sl apparently is threaded (your earlier error message).

That means that perl (and intermediate libraries) needs to be threaded
or
you need to pull libjava.sl out of libclntsh.cl (not fun - unless you mess with Oracle a bunch) - see sysliblist
or
you need to build a static DBD (it'll use the *.a files).
Ajay Bansal_1
Occasional Contributor

Re: Perl DBD::Oracle Failure

Hi

I am also facing the same proble with oracle 8.1.7 & HP 11i. as per the previous suggestions I have rebuild my perl with threaded option. But still the problem will not go away.

I am geting following error :
/home/hpux/ajay/project/sdk/CLI/policymgtapi >make test
PERL_DL_NONLAZY=1 /3rdparty/testPerl/bin/perl -Iblib/arch -Iblib/lib -I/
3rdparty/testPerl/lib/perl5/5.6.1/PA-RISC2.0-thread -I/3rdparty/testPerl/lib/per
l5/5.6.1 test.pl
1..1
/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /3r
dparty/oracle817/OraHome1/JRE/lib/PA_RISC/native_threads/libjava.sl
/usr/lib/dld.sl: Exec format error
Can't load 'blib/arch/auto/Infy/MyMgtAPI/MyMgtAPI.sl' for module Ne
tegrity::PolicyMgtAPI: Exec format error at /3rdparty/testPerl/lib/perl5/5.6.1/P
A-RISC2.0-thread/DynaLoader.pm line 206.
at test.pl line 10
Compilation failed in require at test.pl line 10.
BEGIN failed--compilation aborted at test.pl line 10.
*** Error exit code 255

Stop.
/home/hpux/ajay/project/sdk/CLI/policymgtapi >