Perl DBD Oracle installs on Oracle 8.1.7 64 but NOT on 8.1.7 32 !!!????????

[Henrique Silva_3]

Ok, this is a weird one.

This is on hpux 11.0 64 bit OS.

Have oracle 8.1.7.3 32 bit installed. Could compile DBI Sybase but not DBD Oracle.
It is failing when trying to compile the OCI stuff. Error message follows :

he Oracle DBI can't seem to load properly when attempting to do the 'make test' step of the Oracle DBI module installation:

*************
/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
/usr/lib/dld.sl: Exec format error

Well, after looking around and not seeing anybody that got this going on 32 bit oracle8.1.7, I decided to install 64 bit oracle. Done that, created an instance and

IT WORKS !!!! I am able to get in dbish and all.

Go back to the 32 bit ORACLE_HOME, and NO, it does not work, same error !!!

So, I know I can compile with the 64 bit. Bad news is that I do not have any 64 bit on production right now and need the 32 bit version to work for us.

Is there a trick here ? Maybe move some of the library files from the 64 bit path and relink them on the 32 bit side ? Maybe there is an oracle or HPUX patch here ? These systems are pretty well patched up on the HPUX side, but the oracle side is virgin. No patches after installation.

Any help will be appreciated here.

Henrique Silva

[Francois Bariselle_3]

Hi,

I'm not sure but in first step, may sure that your liboracle.sl file is on our $SH_LIB path directory.

I'm not sure but check your good environement variable in .profile of your user oracle.

Frank.

[H.Merijn Brand (procura]

Can it be you have a 64bit perl build? Please check with

perl -V

if the is a -Duse64bitint or -Duse64bitall in the report, hp-ux gives you little chance of using a combination of this 64bit build with 32bit builds (at least not with dynamic loading). In that case there's no other solution than to build a second 32bit perl. You'll never be able to connect Sybase/64 with Oracle/32 through perl or any other dynamic loading program.

[Angus Crome]

We just did this on Tuesday. We found that we could not build the 32 Bit using the HP provided Perl5.6.1. We had to recompile and build the latest stable 5.6.1 from the GNU perl site using dynamic linking. After that the DBI and DBD re-compiled for both 32 and 64 bit.
Works real slick too, our applications folks are pretty happy now.

I believe we are running against Oracle 8.1.7.0 and 8.1.7.3 for this build.

[Angus Crome]

One other thing. The Notes on the Perl build specifically mention Oracle on HP-UX because it uses libpthreads.

[MANOJ SRIVASTAVA]

Henrique Silva

Here is the way you can do it . Go to this link

http://www.sas.com/service/techsup/unotes/SN/001/001875.html

follow the process and you are good to go .


Manoj Srivastava

[Henrique Silva_3]

That sounds encoraging Angus.

Our environment is correct, perl -V says :

$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=hpux, osvers=11.00, archname=PA-RISC2.0-thread
uname='hp-ux hpandhw b.11.00 a 9000800 894337431 two-user license '
config_args='-Ubincompat5005'
hint=previous, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='+z -D_HPUX_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae',
optimize='-O',
cppflags='+z -D_HPUX_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae'
ccversion='B.11.11.04', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='ld', ldflags =' -Wl,+vnocompatwarnings -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lcl -lpthread -lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lsec
perllibs=-lcl -lpthread -lnsl -lnm -ldld -lm -lc -lndir -lcrypt -lsec
libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
cccdlflags='+z', lddlflags='-b +vnocompatwarnings -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under hpux
Compiled at Apr 5 2002 08:12:08
@INC:
/opt/perl5/lib/5.6.1/PA-RISC2.0
/opt/perl5/lib/5.6.1
/opt/perl5/lib/site_perl/5.6.1/PA-RISC2.0
/opt/perl5/lib/site_perl/5.6.1
/opt/perl5/lib/site_perl
.

C compiler is :

$ which cc
/usr/ccs/bin/cc

We got perl 5.6.1 from CPAN. I will look at the GNU site.

Also, can you send me the perl -V output ? I want to see what options your perl was compiled under, and maybe the config file too ? I am not doing this myself, so, I have to be the middle man here !!! Pass the info along, and when I have time, I will jump and help too.

Thanks,

Henrique Silva

[Angus Crome]

Oops, sorry Henrique, I mis-spoke. We also got our source from CPAN. As for the 32-bit. The applications folks said that they didn't really test it and had decided to go with the 64 bit, since we are slowly migrating our Oracle DB's and Applications to 64-bit compilations. When they tried it late Friday afternoon, they started getting core dumps from the 32-bit build. I am trying to trace down why, so I can report it back to the CPAN site. The attachment is for the 64-bit. The compile may be hosed for 32-bit, because perl -V is coming back with all kinds of library mismatch errors.