Getting cpan's Oracle DBD to work properly on i386 is proving a bit tricky

Chris Benson chrisb at ccandc.org
Mon Aug 22 21:24:51 BST 2011


On Mon, Aug 22, 2011 at 05:17:07PM +0100, Paul Branon wrote:
> Hi Guys,
> 
> Does anyone know where I can get help getting oracle DBD to work? I'm on
> Intel Solaris 10
> and Oracle comes with an AMD64 binary. It runs fine on my system. I can
> connect to oracle
> with no problems at all. Then I install oracle DBD which installs just fine
> But when I try to
> connect to the database I get wrong ELF class. Because libclntsh.so.10.1 is
> a 32 bit binary.

Uhm for my sins, I've got:
root at selfservice:/usr/local # uname -a
SunOS selfservice 5.10 Generic_142901-07 i86pc i386 i86pc
oot at selfservice:/usr/local # file /usr/local/oracle/product/instantclient_10_2/libclntsh.so.10.1 
/usr/local/oracle/product/instantclient_10_2/libclntsh.so.10.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped
root at selfservice:/usr/local #
 
... and I think what makes it possible:
root at selfservice:/usr/local # file /usr/local/bin/perl
/usr/local/bin/perl:    ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
root at selfservice:/usr/local # 

Which was either from sunfreeware.com or locally built.

On some SPARC systems where there's a full 64bit Oracle installed, I've
resorted to ensuring that I've set
	ORACLE_HOME=/export/home/oracle1020/product/1020/client_1/
	LD_LIBRARY_PATH=$ORACLE_HOME/lib32
	export ORACLE_HOME LD_LIBRARY_PATH
before starting or where I can't/don't trust the environment to:
BEGIN {
  # needs to before loading the DB modules
  $ENV{ORACLE_HOME} ||= '/export/home/oracle1020/product/1020/client_1';
  # LD_LIBRARY_PATH needed because we're on a 64bit Oracle now
  $ENV{LD_LIBRARY_PATH} ||= "$ENV{ORACLE_HOME}/lib32:$ENV{ORACLE_HOME}/network/lib32";
}
But again this is with a 32-bit Perl.
# file /usr/local/bin/perl
/usr/local/bin/perl:    ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped

> I guess what I need is literally the answer.

Install a 32-bit Perl has been my solution.  I'll need to look at
this again soon for the next technology refresh though :-/  

I'm hoping it won't be as irritating on RHEL/OUL, but my first attempts
to setup an application server for Oracle 11g ended up rebuilding the
whole system as 32-bit because the application vendor had linked their
app against a 32-bit libclntsh and 32-bit Oracle 11g won't install on a 
64-bit o/s ...

HTH
-- 
Chris Benson


More information about the london.pm mailing list