Problem on Solaris 8 64-bit.

------=_Part_8068_26746625.1143756078407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I'm running Oracle 10.2.0.1 on Solaris 8 64-bit. I running DBI 1.50,
DBD::Oracle 1.16, and Perl 5.8.7.

When I run a script that uses DBD::Oracle, it complains about wrong ELF
class:

Can't load
'/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/ Oracle/Oracle.s=
o'
for module DBD::Oracle: ld.so.1: snapshot_tracker: fatal:
/u01/app/oracle/product/10.2/lib/libclntsh.so.10.1: wrong ELF class:
ELFCLASS64 at /usr/local/lib/perl5/5.8.7/sun4-solaris/DynaLoader.pm line
230.
at ./snapshot_tracker line 10
Compilation failed in require at ./snapshot_tracker line 10.
BEGIN failed--compilation aborted at ./snapshot_tracker line 10

Even if I set LD_LIBRARY_PATH=3D/u01/app/oracle/product/10.2/lib32 in my sh=
ell
environment and also explicitly set this using $ENV inside my script it
still complains. If I copy the 32-bit client library into the
/u01/app/oracle/product/10.2/lib directory my perl scripts work but then
sqlplus is broken. (and subsequently all my shell scripts)

Have I built DBD::Oracle incorrectly or how can I get DBI/DBD to use the
library under lib32? (I would like to get DBD::Oracle to use the 64-bit
library)

Thanks for any help,
CC

------=_Part_8068_26746625.1143756078407--

Re: Problem on Solaris 8 64-bit.

------=_Part_10952_30248118.1143763545810
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/30/06, Rhugga Harper wrote:
>
> I'm running Oracle 10.2.0.1 on Solaris 8 64-bit. I running DBI 1.50,
> DBD::Oracle 1.16, and Perl 5.8.7.
>
> When I run a script that uses DBD::Oracle, it complains about wrong ELF
> class:
>
> Can't load
>
> '/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/ Oracle/Oracle=
..so'
> for module DBD::Oracle: ld.so.1: snapshot_tracker: fatal:
> /u01/app/oracle/product/10.2/lib/libclntsh.so.10.1: wrong ELF class:
> ELFCLASS64 at /usr/local/lib/perl5/5.8.7/sun4-solaris/DynaLoader.pm line
> 230.
> at ./snapshot_tracker line 10
> Compilation failed in require at ./snapshot_tracker line 10.
> BEGIN failed--compilation aborted at ./snapshot_tracker line 10
>
> Even if I set LD_LIBRARY_PATH=3D/u01/app/oracle/product/10.2/lib32 in my
> shell
> environment and also explicitly set this using $ENV inside my script it
> still complains. If I copy the 32-bit client library into the
> /u01/app/oracle/product/10.2/lib directory my perl scripts work but then
> sqlplus is broken. (and subsequently all my shell scripts)
>
> Have I built DBD::Oracle incorrectly or how can I get DBI/DBD to use the
> library under lib32? (I would like to get DBD::Oracle to use the 64-bit
> library)
>
> Thanks for any help



Is your Perl a 32-bit or a 64-bit version? If you want to use the 64-bit
Oracle libraries, you'll need a 64-bit Perl.

If you'd included the output of 'perl -V', we could have told you what
you've got - you didn't, so we can't.




--
Jonathan Leffler #include
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."

------=_Part_10952_30248118.1143763545810--

Re: Problem on Solaris 8 64-bit.

------=_Part_1994_288653.1144075112351
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/30/06, Jonathan Leffler wrote:
>
>
>
> On 3/30/06, Rhugga Harper wrote:
> >
> > I'm running Oracle 10.2.0.1 on Solaris 8 64-bit. I running DBI 1.50,
> > DBD::Oracle 1.16, and Perl 5.8.7.
> >
> > When I run a script that uses DBD::Oracle, it complains about wrong ELF
> > class:
> >
> > Can't load
> >
> > '/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/ Oracle/Orac=
le.so'
> > for module DBD::Oracle: ld.so.1: snapshot_tracker: fatal:
> > /u01/app/oracle/product/10.2/lib/libclntsh.so.10.1: wrong ELF class:
> > ELFCLASS64 at /usr/local/lib/perl5/5.8.7/sun4-solaris/DynaLoader.pm lin=
e
> > 230.
> > at ./snapshot_tracker line 10
> > Compilation failed in require at ./snapshot_tracker line 10.
> > BEGIN failed--compilation aborted at ./snapshot_tracker line 10
> >
> > Even if I set LD_LIBRARY_PATH=3D/u01/app/oracle/product/10.2/lib32 in m=
y
> > shell
> > environment and also explicitly set this using $ENV inside my script it
> > still complains. If I copy the 32-bit client library into the
> > /u01/app/oracle/product/10.2/lib directory my perl scripts work but the=
n
> > sqlplus is broken. (and subsequently all my shell scripts)
> >
> > Have I built DBD::Oracle incorrectly or how can I get DBI/DBD to use th=
e
> > library under lib32? (I would like to get DBD::Oracle to use the 64-bit
> > library)
> >
> > Thanks for any help
>
>
>
> Is your Perl a 32-bit or a 64-bit version? If you want to use the 64-bit
> Oracle libraries, you'll need a 64-bit Perl.
>
> If you'd included the output of 'perl -V', we could have told you what
> you've got - you didn't, so we can't.
>
>
>
>
> --
> Jonathan Leffler < jonathan.leffler@gmail.com> #include
> Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
> "I don't suffer from insanity - I enjoy every minute of it."
>


This is a 32-bit version of perl. Building a 64-bit version isn't an option
as it would take months to get it certified for deployment onto production
gear. (assuming of course that it will pass certification) Is there any way
to force perl itself or anything I can do with each script to have it use
$ORACLE_HOME/lib32. LD_LIBRARY_PATH is being ignored.

All our Linux/HP-UX hosts are fine, we only have this issue on Solaris
hosts.

Thanks for any help,
CC

------=_Part_1994_288653.1144075112351--

RE: Problem on Solaris 8 64-bit.

=20

> -----Original Message-----
> From: Rhugga Harper [mailto:rhugga@gmail.com]=20
> Sent: Monday, April 03, 2006 10:39 AM
> To: Jonathan Leffler
> Cc: dbi-users@perl.org
> Subject: Re: Problem on Solaris 8 64-bit.
>=20
> On 3/30/06, Jonathan Leffler wrote:
> >
> > On 3/30/06, Rhugga Harper wrote:
> > >
> > > I'm running Oracle 10.2.0.1 on Solaris 8 64-bit. I running DBI
> > > 1.50, DBD::Oracle 1.16, and Perl 5.8.7.
> > >
> > > When I run a script that uses DBD::Oracle, it complains about
> > > wrong ELF class:
> > >
> > > Can't load
> > >
> > >
'/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/ Oracle/Oracl
e.so'
> > > for module DBD::Oracle: ld.so.1: snapshot_tracker: fatal:
> > > /u01/app/oracle/product/10.2/lib/libclntsh.so.10.1: wrong ELF
class:
> > > ELFCLASS64 at
/usr/local/lib/perl5/5.8.7/sun4-solaris/DynaLoader.pm=20
> > > line 230.
> > > at ./snapshot_tracker line 10
> > > Compilation failed in require at ./snapshot_tracker line 10.
> > > BEGIN failed--compilation aborted at ./snapshot_tracker line 10
> > >
> > > Even if I set LD_LIBRARY_PATH=3D/u01/app/oracle/product/10.2/lib32
> > > in my shell environment and also explicitly set this using $ENV
> > > inside my script it still complains. If I copy the 32-bit client
> > > library into the /u01/app/oracle/product/10.2/lib directory my
> > > perl scripts work but then sqlplus is broken. (and subsequently
> > > all my shell scripts)
[snip]
>=20
> This is a 32-bit version of perl. Building a 64-bit version isn't an
> option as it would take months to get it certified for deployment onto
> production gear. (assuming of course that it will pass certification)
> Is there any way to force perl itself or anything I can do with each
> script to have it use $ORACLE_HOME/lib32. LD_LIBRARY_PATH is being
> ignored.


If you run:

LD_DEBUG=3Dlibs perl -MDBD::Oracle -e1

You'll see what paths the dynamic linker is searching for the Oracle
libs. Maybe that will help.

Philip

Re: Problem on Solaris 8 64-bit.

Garrett, Philip (MAN-Corporate) wrote:

> If you run:
>
> LD_DEBUG=libs perl -MDBD::Oracle -e1
>
> You'll see what paths the dynamic linker is searching for the Oracle
> libs. Maybe that will help.

Easier still, run

dump -Lv
/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/O racle/Oracle.so

and see what path is being used to load up the Oracle libraries. You
may find that the path to libclntsh.so.10.1 is hard-coded in Oracle.so,
so setting LD_LIBRARY_PATH won't have any effect. Easiest thing is to
install the Oracle 32-bit client somewhere and build DBD::Oracle against
that instead of the 64-bit one.

--
Alan Burlison
--

Re: Problem on Solaris 8 64-bit.

You might be onto something Philip I know if you are trying to use the
instant client the Make file will
hard coded link something like this "ln -s libclntsh.so.10.1 libclntsh.so"

Perhaps in a 64 bit world you do not need this link?

Unfortunately I do not have a 64bit box to test on so I can only give a
rough opinion.

cheers
John Scoles

"Alan Burlison" wrote in message
news:44322C7B.1080709@sun.com...
> Garrett, Philip (MAN-Corporate) wrote:
>
> > If you run:
> >
> > LD_DEBUG=libs perl -MDBD::Oracle -e1
> >
> > You'll see what paths the dynamic linker is searching for the Oracle
> > libs. Maybe that will help.
>
> Easier still, run
>
> dump -Lv
>
/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/O racle/Oracle.so
>
> and see what path is being used to load up the Oracle libraries. You
> may find that the path to libclntsh.so.10.1 is hard-coded in Oracle.so,
> so setting LD_LIBRARY_PATH won't have any effect. Easiest thing is to
> install the Oracle 32-bit client somewhere and build DBD::Oracle against
> that instead of the 64-bit one.
>
> --
> Alan Burlison
> --

Re: Problem on Solaris 8 64-bit.

------=_Part_3080_33188545.1144853188787
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It is looking in $ORACLE_HOME/lib:

adcnaa02:/usr/local/internal/log #dump -Lv
Usage: dump [-agcd:fhn:oprstvCLT:V?] file(s) ...
adcnaa02:/usr/local/internal/log
#/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/ Oracle/Oracle.s=
o


adcnaa02:/usr/local/internal/log #dump -Lv
/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/O racle/Oracle.so

/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/O racle/Oracle.so=
:

**** DYNAMIC SECTION INFORMATION ****
..dynamic:
[INDEX] Tag Value
[1] NEEDED libclntsh.so.10.1
[2] NEEDED libkstat.so.1
[3] NEEDED libnsl.so.1
[4] NEEDED libsocket.so.1
[5] NEEDED libgen.so.1
[6] NEEDED libdl.so.1
[7] NEEDED libsched.so.1
[8] NEEDED libaio.so.1
[9] NEEDED librt.so.1
[10] NEEDED libm.so.1
[11] NEEDED libthread.so.1
[12] NEEDED libpthread.so.1
[13] NEEDED libc.so.1
[14] INIT 0x198d4
[15] FINI 0x198f0
[16] RUNPATH /u01/app/oracle/product/10.2/lib
[17] RPATH /u01/app/oracle/product/10.2/lib
[18] HASH 0x94
[19] STRTAB 0x1878
[20] STRSZ 0x108a
[21] SYMTAB 0x898
[22] SYMENT 0x10
[23] CHECKSUM 0xb9f9
[24] VERNEED 0x2904
[25] VERNEEDNUM 0x1
[26] TEXTREL 0
[27] PLTSZ 0x7f8
[28] PLTREL 0x7
[29] JMPREL 0x45f8
[30] RELA 0x2924
[31] RELASZ 0x24cc
[32] RELAENT 0xc
[33] FEATURE_1 PARINIT
[34] FLAGS TEXTREL
[35] FLAGS_1 0
[36] PLTGOT 0x2e9f0


Ugh. Im at a loss on this issue. I can't switch to a 64-bit build of
perl....

Any ideas??


On 4/4/06, John Scoles wrote:
>
> You might be onto something Philip I know if you are trying to use the
> instant client the Make file will
> hard coded link something like this "ln -s libclntsh.so.10.1 libclntsh.so=
"
>
> Perhaps in a 64 bit world you do not need this link?
>
> Unfortunately I do not have a 64bit box to test on so I can only give a
> rough opinion.
>
> cheers
> John Scoles
>
> "Alan Burlison" wrote in message
> news:44322C7B.1080709@sun.com...
> > Garrett, Philip (MAN-Corporate) wrote:
> >
> > > If you run:
> > >
> > > LD_DEBUG=3Dlibs perl -MDBD::Oracle -e1
> > >
> > > You'll see what paths the dynamic linker is searching for the Oracle
> > > libs. Maybe that will help.
> >
> > Easier still, run
> >
> > dump -Lv
> >
>
> /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/O racle/Oracle.=
so
> >
> > and see what path is being used to load up the Oracle libraries. You
> > may find that the path to libclntsh.so.10.1 is hard-coded in Oracle.so,
> > so setting LD_LIBRARY_PATH won't have any effect. Easiest thing is to
> > install the Oracle 32-bit client somewhere and build DBD::Oracle agains=
t
> > that instead of the 64-bit one.
> >
> > --
> > Alan Burlison
> > --
>
>
>

------=_Part_3080_33188545.1144853188787--