Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?

Dr James A Smith <[email protected]>
Newsgroups gmane.comp.apache.mod-perl
Message-ID <[email protected]>
You may have some "quirk" going on with DBD::Oracle - it has a nasty 
BEGIN block in it which
does some nasty stuff... I had a three day head scratch with this module 
moving from Lucid to
Precise as it was not finding the tnsnames files - in the end I had to 
set up the environment
before starting up apache. As the Env settings int the config were not 
in place when DBD::Oracle
was used for the first time. Not sure when it is being used tho' but it 
took a lot of "root"y
hacking to discover the problem!

James

On 21/10/2013 19:37, Bruce Johnson wrote:
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <[email protected]> wrote:
>
>> 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?
> Nope, good idea but the vars I need are present, even with the modperl handler in place. The only ones you need for DBD::Oracle to work are ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
>> 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.
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> 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-> .
>
> server:
>
> 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
>
>
>>
>> On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <[email protected]> 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
>>
>>
>>


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.