Just a wild guess:
mod_perl sets %ENV, but *AFTER* loading DBD::Oracle, so the XS part of
DBD::Oracle won't see the required environment variables. It is possible
to manipulate %ENV from inside Perl (this includes mod_perl) and then
load DBD::Oracle, or at least it was possible for a long time.
I would try to make mod_perl execute something like the following code
as early as possible, even before DBI is loaded:
$ENV{'ORACLE_HOME'}='/some/where';
# maybe set up other Oracle related environment variables
require DBD::Oracle; # loads the XS part AFTER setting up the environment
Alexander
On 21.10.2013 23:36, Bruce Johnson wrote:
Nope, built and run with the same path, same install. I installed the Instant
Client Basic and Development packages via the rpms, set up the proper
environment variables, used cpan to install DBI, then DBD::Oracle and both
built without any errors.
It's absolutely a mod_perl handler thing, I just don't know where the problem
is. It's acting as though it's ignoring its environment settings, even though a
perl script run by that handler says the environment is correct.
On Oct 21, 2013, at 2:19 PM, "Furst, Carl" <carl.fu...@mlb.com> wrote:
So did you build DBD::Oracle with that LD_LIBRARY_PATH?
And against that install?
Maybe Oracle.so is using LD_LIBRARY_PATH set at build time instead of
runtime?
Carl Furst
On 10/21/13 4:03 PM, "Bruce Johnson" <john...@pharmacy.arizona.edu> wrote:
On Oct 20, 2013, at 1:03 PM, Bruce Johnson <john...@pharmacy.arizona.edu>
wrote:
Oh it turned out to be even simpler than that, and for once it wasn't
MY fat fingers that fat fingered it this time :-)
Cue the sad trombone, because I was wrong, again.
It turns out the issue seems to have something to do with mod_perl.
It works find from the command line, it works fine when the script is
executed as a classic CGI script, it fails when run as a mod_perl handler
with an error that indicates that LD_LIBRARY_PATH is wrong or missing.
I can recreate the error in CGI mode by commenting out the server
directive 'SetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib'
When I found the errors in the conf file, I didn't know that my co-worker
had tried that because he'd read that in some web page somewhere and he
was starting to get desperate, because nothing was working.
I have, however managed to isolate the problem, and it's got to do with
mod_perl
I'm chasing this on the mod_perl list, but without much luck and am
hoping if anyone else has run into this issue using mod_perl and
DBD::Oracle.
We've set a directory to be handled by mod_perl as follows:
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>
With those directives in place, I get the error every time. (I've added
ORACLE_SID and TNS_ADMIN to the PerlSetEnv declarations, but it makes no
difference.
LD_LIBRARY_PATH is set, this is the contents of %ENV and %INC according
to the server, with that mod_perl directive in place:
DOCUMENT_ROOT --> /home/allwebfiles/static
GATEWAY_INTERFACE --> CGI/1.1
HTTPS --> on
HTTP_ACCEPT -->
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
HTTP_ACCEPT_ENCODING --> gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE --> en-US,en;q=0.8
HTTP_CONNECTION --> keep-alive
HTTP_COOKIE --> __qca=P0-1946018635-1381167733063;
SESS360e9fa4a6458358b044501f2b5b21b9=4862153113fc157562a1fc7691eecb36;
__utma=219252696.1214622818.1382045504.1382045504.1382045504.1;
__utmz=219252696.1382045504.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(no
ne); CASAUTHOK=1; COPInt=ghZxjY9mJ74QPBgWE13I8cGha
HTTP_HOST --> xxxxx.pharmacy.arizona.edu
HTTP_USER_AGENT --> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
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
QUERY_STRING -->
REMOTE_ADDR --> 128.196.45.237
REMOTE_PORT --> 49295
REQUEST_METHOD --> GET
REQUEST_URI --> /card_access/envvars.pl
SCRIPT_FILENAME --> /home/allwebfiles/perl/catcard/envvars.pl
SCRIPT_NAME --> /card_access/envvars.pl
SERVER_ADDR --> 150.135.124.49
SERVER_ADMIN --> root@localhost
SERVER_NAME --> xxxxx.pharmacy.arizona.edu
SERVER_PORT --> 443
SERVER_PROTOCOL --> HTTP/1.1
SERVER_SIGNATURE -->
Apache/2.2.15 (Red Hat) Server at xxxxx.pharmacy.arizona.edu Port 443
SERVER_SOFTWARE --> Apache/2.2.15 (Red Hat)
SSL_TLS_SNI --> xxxx.pharmacy.arizona.edu
INC
INC-> /usr/local/lib64/perl5
INC-> /usr/local/share/perl5
INC-> /usr/lib64/perl5/vendor_perl
INC-> /usr/share/perl5/vendor_perl
INC-> /usr/lib64/perl5
INC-> /usr/share/perl5
INC-> .
INC-> /etc/httpd
But attempting to create a database handle results in:
[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
EVEN THOUGH libocci.so.11.1 is right where it's supposed to be, in
$LD_LIBRARY_PATH.
# cd $LD_LIBRARY_PATH
# pwd
/usr/lib/oracle/11.2/client64/lib
# ls -al
total 185024
drwxr-xr-x 2 root root 4096 May 20 12:07 .
drwxr-xr-x 5 root root 4096 May 20 14:12 ..
-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
Has anyone run into this before?
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
**********************************************************
MLB.com: Where Baseball is Always On
--
Alexander Foken
mailto:alexan...@foken.de http://www.foken.de/alexander/
