This is annoying but it happens on 64 bit architectures.
> The path is correct, the script works fine on the command line, and if I
comment out the handler directives in the perl.conf script, put in a
ScriptAlias and process the script as a normal CGI script, it also works.
Sounds like some environment variable is not getting passed correctly to
mod_perl. Maybe dump out %ENV from the command line and see if there are
additional vars you need to pass?
I'd dump out %INC from the command line and mod_perl also to make sure that
you are loading the needed modules. You could try to install DBD::Oracle in
/usr/lib instead of /usr/local/lib also - my guess is that it's looking for
the Oracle.so in /usr/local/lib but it is located somewhere else.
On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <
john...@pharmacy.arizona.edu> wrote:
> We've set a Directory directive for some perl scripts, setting a mod_perl
> handler:
>
> Alias /card_access /home/allwebfiles/perl/catcard
>
> <Directory /home/allwebfiles/perl/catcard>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> </Directory>
>
> The %ENV variable is there, if I print the %ENV values:
>
> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> MOD_PERL --> mod_perl/2.0.4
> MOD_PERL_API_VERSION --> 2
> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>
> But trying to initialize a DBI database connection results in the
> following error:
>
> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't
> load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module
> DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file
> or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11)
> line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a
> required shared library or dll isn't installed where expected\n at
> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>
> Which is precisely the error you get when LD_LIBRARY_PATH is unset or
> incorrect.
>
> libocci.so.11.1 is where it's supposed to be.
>
> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> total 185016
> -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so ->
> libclntsh.so.11.1
> -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
> -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
>
> The path is correct, the script works fine on the command line, and if I
> comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
>
> I'm confident the issue doesn't have anything to do with DBI or
> DBD::Oracle.
>
> It ONLY fails when the script is executed as a mod_perl handler.
>
> The script itself is very simple; all I do is create a database handle and
> if no error is thrown, print 'It works'.
>
> #!/usr/bin/perl
> use DBI;
> use strict;
>
> my $login="xxxxxx";
> my $dbpass='xxxxxxxx';
> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError
> =>1});
>
> print "Content-type: text/html\n\n";
> print "It Works";
> exit;
>
> (and this is just a test , any script using DBI fails with this error.)
>
> What am I missing?
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
