Perl and DBD:Oracle...

[Scott Nipp]

Here starts yet another thread related to Perl and DBD:Oracle on HPUX... I am currently running Perl 5.6.1, the HP compiled version, on HPUX 11.11. I am attempting to compile DBD:Oracle 1.16. Of course, I am running into problems.

This Perl version is the HP version. Of course, the DBD:Oracle module is not built into the package, but that's OK. The problem is that the README.hpux seems to start with recompiling Perl with specific options, and I have done this before successfully. Right now, I would like to try and figure out if there is a way to make this work with the default HP version of Perl.

The make completes, but the make test pukes with the following...

t/01base............/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2
/usr/lib/dld.sl: Exec format error
Failed to load Oracle extension and/or shared libraries:
install_driver(Oracle) failed: Can't load 'blib/arch/auto/DBD/Oracle/Oracle.sl' for module DBD::Oracle: Exec format error at /opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi/DynaLoader.pm line 206.
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
The remaining tests will probably also fail with the same error.

*** Please read the README and README.help files for help. ***


This is just where the errors begin. Thanks in advance for any help.

Scott

[Jim Butler]

Try re-linking your oracle install (I don't remember the exact syntax, but try something like:

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk install

Also, check the value of your env variable

LD_LIBRARY_PATH and make sure that is properly set.

Good luck

[harry d brown jr]

try perl 5.8.3:

http://www.cmve.net/~merijn/

then install the module.

live free or die
harry d brown jr

[Scott Nipp]

OK... I downloaded and installed Perl 5.8.6 from Merijn. I then tried to build the DBD module and here is what I am seeing.

t/01base................/usr/lib/dld.sl: Unresolved symbol: ociepgoe (code) from /www/tmp/DBD-Oracle-1.16/blib/arch/auto/DBD/Oracle/Oracle.sl
Failed to load Oracle extension and/or shared libraries:
install_driver(Oracle) failed: Can't load '/www/tmp/DBD-Oracle-1.16/blib/arch/auto/DBD/Oracle/Oracle.sl' for module DBD::Oracle: Unresolved external at /opt/perl/lib/5.8.6/PA-RISC2.0/DynaLoader.pm line 230.
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
at t/01base.t line 19
The remaining tests will probably also fail with the same error.


These are the errors from the 'make test'.

Scott

[Scott Nipp]

I am still at a stand still on this. I was hoping that the information I included in my previous post would help someone come up with the answer. I really need to get Oracle access working on this system, and I am at a dead end at the moment. Thanks again for any help.

Scott

[Florian Heigl (new acc)]

scott,
drop me a line tomorrow, I still have a DBD::Oracle-tested 5.6.1 around somewhere. The issue with HP's 5.6.1 is that it doesn't have full thread support. (iirc)

but I haven't played around with these things for 3 years, so probably someone has the solution before i rise from bed again ;)

[T G Manikandan]

Just do a

chatr 'blib/arch/auto/DBD/Oracle/Oracle.sl'

and check the libraries that are dependent.

Also make sure that you are pointing the right libraries.

[H.Merijn Brand (procura]

What I still don't see is what Oracle you're running. If it is a 64bit Oracle, you also need a 64bit perl (and 32bit with 32 bit)

For the 64bit combination you did right in upgrading to 5.8.6, since 5.6.x isn't very good with 64bit

The first (HP) perl you tried is a pa-risc-1.1 port, and cannot do 64bit.

perl -v

will show you what perl you have, and that should be the same bitness as Oracle

The Ecec format error points me towards a bad combination, but I'm not sure

Enjoy, Have FUN! H.Merijn

[Scott Nipp]

I am running 32 bit Oracle, and I think I downloaded the 32 bit Perl from your site. Let me know if there is any other information I can provide to help.

Thanks.

Scott

[H.Merijn Brand (procura · Accepted solution]

ociepgoe () is in $ORACLE_HOME/lib/liblntsh.sl

that can either mean two things

1. $ORACLE_HOME is wrong
2. $ORACLE_HOME/lib/liblntsh.sl is not linked in from Oracle.sl (the DBD one)

The first is not likely, because in that case the make would have failed. The second can be checked with either ldd or chatr

# chatr Oracle.sl
# ldd Oracle.sl

After that, first try if everything works if you extend your SHLIB_PATH to would it should have been to start wih:

# export SHLIB_PATH=${ORACLE_HOME}/lib:${SHLIB_PATH:-""}

and run 'make test' again

Then in some cases there might be a situation that would only influence the *test* case.
If that is true on your system, go edit the Makefile, and remove 'PERL_DL_NOLAZY=1 ' from the Makefile (make a backup first)

I think your `helpers' would also like to see what oracle version you run

Enjoy, Have FUN! H.Merijn

[Jim Butler]

Scott -

I just re-read your thread, and have an opinion FWIW -
It looks like your perl is running PA-RISC 1.1, but yoiu are on HP11.11 - what is the model of the machine you are running on? It could be that the oracle installation is compliled using PA-RISC 2.0, and thus you are having this issue.

If you load the perl from source, you could set your CCFLAGS to have the -DAPortability flag set so that the perl modules are compatible with external executables.

[H.Merijn Brand (procura]

Jim, no. The fact that the test made it to that error proves that he has a pa-risc-2.0 machine.

I'd also like to see the uname -a output

Enjoy, Have FUN! H.Merijn

[Scott Nipp]

Here is the info and the model also.

root@thp016a:/www/tmp> uname -a
HP-UX thp016a B.11.11 U 9000/800 625319393 unlimited-user license
root@thp016a:/www/tmp> model
9000/800/N4000-55


Scott

[H.Merijn Brand (procura]

Did you try the SHLIB_PATH stuff already?

(when this problem is solved, please also thing about your points: for *all* answers:
http://forums1.itrc.hp.com/service/forums/pageList.do?userId=CA527977&listType=unassigned&forumId=1
it's like the forum way to say "thank you for your time and effort")

Enjoy, Have FUN! H.merijn

[Scott Nipp]

This has finally come up as being an issue yet again. I am still stuck at the same point as last time.

I have tried the SHLIB stuff, and still no luck. This is getting very frustrating. I wish HP would just put out a version of Perl that would work with or include DBD::Oracle.

Please help. Please let me know what you need to see to hopefully get me past this. Thanks.

Scott

[Scott Nipp]

SUCCESS at last!!!

The fix was removing the PERL_NONLAZY=1. his caused the 'make test' to complete quickly and with relatively few errors, and then the build worked.

Thanks for the help

Scott

[H.Merijn Brand (procura]

As /me quoteths /me from a previous post:

--8<---
Then in some cases there might be a situation that would only influence the *test* case.
If that is true on your system, go edit the Makefile, and remove 'PERL_DL_NOLAZY=1 ' from the Makefile (make a backup first)
-->8---

Didn't I tell you? :)

And it's *very* easy to explain why HP cannot ship a working DBD::Oracle. It is the same reason why *I* can't, and I explain again

1. There are many Oracle versions, and a port of DBD::Oracle for Oracle 9.1.0.2/32 will not work for Oracle 9.1.0.3/64 however small the difference might look
2. The installation path for Oracle will be different on every system, and as the library path to Oracle's shared libs is included in the modules, and not all environments will gladly accept SHLIB_PATH, things wil just not work, even if your version exacly matches the version DBD::Oracle was built against. e.g. my own Oracle is installed in /pro/oracle/v920. I bet yours is somewhere else
3. Installing DBD::Oracle *inside* the default perl tree will prevent seemless installation of several DBD::Oracle's beside eachother, as to run for multiple versions of Oracle on the same machine
4. If you get a prebuilt DBD::Oracle, and you expect it to still work after you upgrade your database, you will find yourself into far more frustration than when you have a hard time building it yourself from the first time. The first time there is far less presure, since nothing works anyway. If you upgrade and things break, look at who people will turn to to complain

Enjoy, Have FUN! H.Merijn

[ludette coronel]

this is not a solution but a request for how you resolved this issue ... I am having the same issue now