When Oracle-DBD speaks to Oracle

[litarena]

How can I persuade Oracle-DBD to build 64 bit cpan modules?

With luck it may not be necessary to read or pay any attention to the long story that I've typed below
That is if I can get Oracle::DBD to build a 64 bit version of Oracle.so
I think that might solve my problem, which is that oracle x86 only comes in 64 bit versions these days, (I believe) and cpan's oracle DBD is building as a 32 bit module which can't communicate with my 64 bit oracle libraries.
I don't actually know whether or not building a 64 bit version of Oracle.so will solve my problems. But It's certainly worth a try.





#######################################################
The long story. Don't read this unless it becomes necessary later
#########################################################
I've loaded x86 Oracle 10g 10202_database_solx86.zip onto
an Intel Pentium system
running Solaris 10
psrinfo -pv
The physical processor has 2 virtual processors (0 1)
x86 (chipid 0x0 GenuineIntel family 6 model 15 step 13
clock 2200 MHz)
Intel(r) Pentium(r) Dual CPU E2200 @ 2.20GHz

And: These are my system's binaries
/usr/sfw/bin/wget: ELF 32-bit LSB executable 80386 Version
1, dynamically linked, stripped


Oracle's binary installer and setup appears to have filled
my oracle/product/10.2.0/db_1/bin
directory with (mostly) AMD 64 bit binaries. There is a
mixture in there, half a dozen binaries
are 80386 32 bit binaries. But most are AMD 64s.


Now, that doesn't seem to matter to oracle. It works just
fine and sqlplus (which is AMD 64)
works like a treat. But, and it's a bit but,


I need to connect to the database via perl CPAN's Oracle-DBD
file /usr/perl5/site_perl/5.8.4/i86pc-solaris-64int/auto/DBD/Oracle/Oracle.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available


And, to cut a long story short, the connection won't work because Oracle.so is 32bit 80386 and perl's libclntsh.so.10.1 is AMD 64


The webserver error is below:
=========================================================================
here's the apache error
=========================================================================
Wed Jul 27 16:18:48 2011 error client 192.168.1.101 \tinstall_driver(Oracle) failed: Can't load '/usr/perl5/site_perl/5.8 .4/i86pc-solaris-64int/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /export/home/oracle/oracle/prod uct/10.2.0/db_1/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64 at /usr/perl5/5.8.4/lib/i86pc-solaris-64int/DynaLoader.pm li ne 230., ref erer: http://192.168.1.130/Wood-Recycling/add-new-customer.html

[Eliya]

...because Oracle.so is 32bit 80386 and perl's libclntsh.so.10.1 is AMD 64

You probably meant "... Oracle's libclntsh.so.10.1 ...".  Anyhow, the problem most likely is that your existing Perl binary is 32-bit, which means that any XS shared libraries - like DBD::Oracle's Oracle.so - built with/for it are (and must be) 32-bit, too.

In other words, you'd need a 64-bit Perl installation in order to link against an external 64-bit library... — or find a 32-bit version of libclntsh.so.10.1.

[Corion]

Have you eliminated Apache from the problem set?

My guess is that the Oracle environment+libraries that Apache is set up for do not match what your general Perl uses, or tries to use.

First eliminate Apache from the problem. If that does not help, please tell us how you installed DBD::Oracle with it passing its tests. If it didn't pass its testsuite, why did you install it at all?