[Solved] DBD::Oracle 1.46 can't find library

From: Stephen \ Wales (Stephen.Wales_at_riotinto.com)
Date: 02/15/05


Date: Tue, 15 Feb 2005 11:38:36 -0700
To: <dbi-users@perl.org>

Posting this just for the record, in case anyone else has the same
problem as I had and can find the solution via a web search...

Eventually, I recompiled perl with the newest DBI (1.47) and DBD::Oracle
1.16.

I noticed that I was having problems if I did testing without
LD_LIBRARY_PATH set (I use HP, others may use other Unix versions and
may need SHLIB_PATH). It was having trouble loading libwtc9.sl, which
must be somehow involved in calling the DBD::Oracle functions. Once
LD_LIBRARY_PATH was defined, then we had everything working. Next
problem was how to make that environment variable visible to apache.

I entered the following into my httpd.conf in /opt/hpapache2/conf

SetEnv LD_LIBRARY_PATH /oracle/product/9.2.0.2/lib

And now I hav a working perl with Oracle support.

Steve

> ______________________________________________
> From: Wales, Stephen (RTSI)
> Sent: Wednesday, February 02, 2005 10:37 AM
> To: 'dbi-users@perl.org'
> Subject: DBD::Oracle 1.46 can't find library
>
> I had been happily plodding along on oracletool 2.0 for that last 2
> years (a perl cgi script that interrogates Oracle databases), when I
> discovered that there was a new version.
>
> So I downloaded and installed that and found that it didn't work, that
> something that had been added, ora_session_modes in DBD::Oracle
> required version 1.13 or greater of DBD::Oracle (I had 1.12).
>
> After spending a day and a half working out how to get DBD::Oracle
> 1.16, DBI 1.46 and Perl 5.8.5 compiled up for HP-UX 11.11 and Oracle
> 9.2.0.5, I was ready to give it a try.
>
> When I try to invoke oracletool now (either 2.2 or the saved version
> 2.0), I'm getting the following perl error:
>
> Can't load
> '/opt/perl5_64/lib/site_perl/5.8.5/PA-RISC2.0-LP64/auto/DBD/Oracle/Ora
> cle.sl' for module DBD::Oracle: No such
> file or directory at
> /opt/perl5_64/lib/5.8.5/PA-RISC2.0-LP64/DynaLoader.pm line 230.
> at oracletool.pl line 24
> Compilation failed in require at oracletool.pl line 24.
> BEGIN failed--compilation aborted at oracletool.pl line 24.
> [Tue Feb 01 16:35:21 2005] [error] [client 148.175.62.147] Premature
> end of script headers: oracletool.pl
>
>
> Now, I've checked the permissions on
> /opt/perl5_64/lib/site_perl/5.8.5/PA-RISC2.0-LP64/auto/DBD/Oracle/Orac
> le.sl and it appears to be globally readable:
>
> root[2929] rtsihp7 /opt/hpapache2/logs# su - www
>
> [snip HP Copyright info at login]
>
> $ file
> /opt/perl5_64/lib/site_perl/5.8.5/PA-RISC2.0-LP64/auto/DBD/Oracle/Orac
> le.sl
> /opt/perl5_64/lib/site_perl/5.8.5/PA-RISC2.0-LP64/auto/DBD/Oracle/Orac
> le.sl: ELF-64 shared object file - PA-RISC 2.0 (LP64)
> $
>
> Oracletool also comes with a basic test script that connects to the
> database and runs "select sysdate from dual" and reports it. This is
> giving me the same error. Unfortunately I don't know a whole lot
> about perl or Apache.
>
> As another test, I tried to run the example.cgi script mentioned in
> the above paragraph from the command line, and it's reporting the same
> message, so I guess that rules out apache.
>
> Anyone have ideas as to why this can't load?
>
>
> Thanks
> Steve
>
>
> Stephen Wales
> Senior Database Administrator
> Rio Tinto Services Inc.
> Phone: 801-252-3623
> Fax: 801-252-3522
> Mobile: 801-699-1774
> E-mail: stephen.wales@riotinto.com
> "Delivering Superior Service"
>

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.



Relevant Pages

  • [Fwd: Re: failed: ERROR OCIEnvNlsCreate. Check (everything)]
    ... So I think this is a good indicator that this is specifically related to Oracle ENV vars, or something to do with the DBD or DBI. ... the script accesses Oracle fine from a command line. ... Apache itself shouldn't care, but the programs invoked by Apache do. ...
    (perl.dbi.users)
  • Re: failed: ERROR OCIEnvNlsCreate. Check (everything)
    ... Perl CGI on this server for years. ... Most likely are DBD::Oracle, Oracle client libraries, environment variables used by Oracle, and filesystem permission issues. ... Either put the user running Apache into the relevant group, or change the filesystem permissions. ...
    (perl.dbi.users)
  • [Fwd: Re: failed: ERROR OCIEnvNlsCreate. Check (everything)]
    ... So, DBI is ok, and most of Apache is also ok. ... The lone problem is ORACLE 10 access. ... the script accesses Oracle fine from a command line. ... but they should differ between CGI and command line mode. ...
    (perl.dbi.users)
  • Re: preventing a user to start a process
    ... You can use some perl to split the lines to find out how long the processes ... >> located in file systems that allow execution. ... >> are running for a certain period of time and are not the apache. ... Does anyone know a usable script for that ...
    (freebsd-isp)
  • Re: install_driver(Oracle) failed: wrong ELF class: DynaLoader.pm
    ... I'm not the Oracle expert - treat what I say with a pinch of salt. ... So, if your Perl script sets LD_LIBRARY_PATH, ... Try modifying your cron job so that it runs a shell script which sets at ...
    (perl.dbi.users)