You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by John D Groenveld <jd...@elvis.arl.psu.edu> on 2013/10/21 21:57:49 UTC
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
In message <76...@pharmacy.arizona.edu>, Bruce J
ohnson writes:
>DBD::Oracle was properly compiled, else it wouldn't work on the command line,
>either.
Out of my depth with Linux, but perhaps this will help:
$ env - /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Assuming ldd can't find libclntsh.so, try reinstalling DBD::Oracle
with -rpath specified and removing LD_LIBRARY_PATH from your
environment.
<URL:http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html>
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <A9...@Pharmacy.Arizona.EDU>, Bruce J
ohnson writes:
>when I run it with /bin/env -i I get:
>
>/bin/env -i /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>linux-vdso.so.1 =3D> (0x00007fff2d9ff000)
>libocci.so.11.1 =3D> not found
>libclntsh.so.11.1 =3D> not found
>libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00007f55049da000)
>libc.so.6 =3D> /lib64/libc.so.6 (0x00007f5504647000)
>/lib64/ld-linux-x86-64.so.2 (0x00007f5504e43000)
>
>However I don't understand what this means...
It means that you should rebuild DBD::Oracle but add the -rpath
option to the LDFLAGS in the generated Makefile to properly hint
the runtime linker where to find the Oracle Instant Client libraries.
Then you should find every instance of LD_LIBRARY_PATH= in
the shell init files in /etc as well as the ones in your
Apache configuration and remove them.
My WAG is that the Oracle packages for Unbreakable Linux
*un*helpfully added LD_LIBRARY_PATH=/path/to/instantclient_11_2
to your /etc/profile and friends.
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <38...@Pharmacy.Arizona.EDU>, Bruce J
ohnson writes:
># su -s /bin/sh apache
Try again...
<URL:http://man7.org/linux/man-pages/man1/su.1.html>
<URL:http://man7.org/linux/man-pages/man1/env.1.html>
# su -s /bin/sh - apache
$ /bin/env
John
groenveld@acm
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by "Thomas M. Payerle" <pa...@umd.edu>.
On Mon, 21 Oct 2013, Bruce Johnson wrote:
>
> On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <pa...@umd.edu> wrote:
>
>> On Mon, 21 Oct 2013, Bruce Johnson wrote:
>>
>> Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
>>
>
> I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that the point of a PerlSetEnv directive?
>
The PerlSetEnv directive will set LD_LIBRARY_PATH, but the question is whether
it is used in the dynamic loading phase. In the simplest case of a setuid
binary foo, when I run foo, ld.so will ignore LD_LIBRARY_PATH and only search
for libs in the system standard places. To do otherwise allows me to escalate
my privs.
I don't think things are exactly the same when a program like apache dynamically
loads the mod_perl code, which then dynamically loads (or tries to load)
Oracle.so and the oracle client libraries, but presumably, for the same
security reasons, it should ignore LD_LIBRARY_PATH.
And I guess my question should have been is apache setuid/setgid (although
I would check mod_perl as well, but that probably is not relevant).
>> My guess would be that the dependent libraries of Oracle.so are not being
>> picked up for some reason, despite ldd "finding" them. One thing you might try
>> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
>> looks like should be whitespace separated), before starting apache, and see
>> if that gets things to work. Probably not a good long term solution (as
>> likely adds bloat to httpd processes), but will at least confirm that the
>> problem is that it is not finding those libs during the dynamic load.
>
> It's not strictly an Apache problem, because the script works on this server when it's set to run as a CGI program.
>
> Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are not subsitute libraries, they're the only libocci libraries on the system. I've had issues like this when i have both oracle and the instant client running on the same system, but properly setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.
>
The info in your email exchange with John D Groenveld seems to make this moot.
My suggestion of LD_PRELOAD was for the following reasons:
1) CGI scripts get started as new processes, and ld.so will get called and load the perl and all. I believe there are subtle differences between that process
and how everything is loaded when done through dlopen. LD_PRELOAD will load
specified libraries immediately, so if something subtle is breaking so that
dlopen is not finding the proper libraries that Oracle.so depends on, it should
still work if you preload the needed libraries.
2) As John Groenveld showed, it looks like LD_LIBRARY_PATH is getting changed
at some point in the process. LD_PRELOAD occurs early in the process, before
Apache is even loaded, which means there is much less time for anything to
confuse the issue.
I concur that it seemed like what you were doing with LD_LIBRARY_PATH _should_
work, but as it is was not working, and problems with loading of libraries seems
a likely candidate for the cause, I was suggesting trying LD_PRELOAD because
it is a simpler, more easily understood process (at least to me the locating of
shared libraries can sometimes be complicated), and it occurs at an earlier
stage in the process before things get more convoluted. I have in the past
found it an useful tool for debugging problems, at least to the point of
confirming that it _is_ a problem loading the dependent libraries, and which
ones.
>
>
>>
>>>
>>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
>>> wrote:
>>>
>>>> In message <48...@pharmacy.arizona.edu>, Bruce J
>>>> ohnson writes:
>>>>> Nope, that looks right:
>>>>>
>>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>>>> x00007fb39a816000)
>>>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>>> 1 (0x00007fb397f84000)
>>>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>>> 396e5c000)
>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>>>
>>>>>
>>>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>>>> s a CGI script, either, I'd think.
>>>>
>>>> As the webserver user?
>>>> # su - apache
>>>> $ /bin/printenv
>>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>
>>>
>>> # su -s /bin/sh apache
>>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> linux-vdso.so.1 => (0x00007fff047a7000)
>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>>>
>>>
>>> Nope.
>>>
>>> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>>>
>>> It only breaks under mod_perl.
>>>
>>>
>>> --
>>> Bruce Johnson
>>> University of Arizona
>>> College of Pharmacy
>>> Information Technology Group
>>>
>>> Institutions do not have opinions, merely customs
>>>
>>>
>>>
>>
>> Tom Payerle
>> IT-ETI-EUS payerle@umd.edu
>> University of Maryland (301) 405-6135
>> College Park, MD 20742-4111
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Tom Payerle
IT-ETI-EUS payerle@umd.edu
University of Maryland (301) 405-6135
College Park, MD 20742-4111
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <pa...@umd.edu> wrote:
> On Mon, 21 Oct 2013, Bruce Johnson wrote:
>
> Based on path, sounds like you have a 64 bit version of Oracle. I am
> assuming that you verified that your mod_perl is a 64 bit build.
>
yes it is.
> Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
>
I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that the point of a PerlSetEnv directive?
> My guess would be that the dependent libraries of Oracle.so are not being
> picked up for some reason, despite ldd "finding" them. One thing you might try
> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
> looks like should be whitespace separated), before starting apache, and see
> if that gets things to work. Probably not a good long term solution (as
> likely adds bloat to httpd processes), but will at least confirm that the
> problem is that it is not finding those libs during the dynamic load.
It's not strictly an Apache problem, because the script works on this server when it's set to run as a CGI program.
Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are not subsitute libraries, they're the only libocci libraries on the system. I've had issues like this when i have both oracle and the instant client running on the same system, but properly setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.
>
>>
>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
>> wrote:
>>
>>> In message <48...@pharmacy.arizona.edu>, Bruce J
>>> ohnson writes:
>>>> Nope, that looks right:
>>>>
>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>>> x00007fb39a816000)
>>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>> 1 (0x00007fb397f84000)
>>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>> 396e5c000)
>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>>
>>>>
>>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>>> s a CGI script, either, I'd think.
>>>
>>> As the webserver user?
>>> # su - apache
>>> $ /bin/printenv
>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>
>>
>> # su -s /bin/sh apache
>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>> linux-vdso.so.1 => (0x00007fff047a7000)
>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>>
>>
>> Nope.
>>
>> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>>
>> It only breaks under mod_perl.
>>
>>
>> --
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>>
>> Institutions do not have opinions, merely customs
>>
>>
>>
>
> Tom Payerle
> IT-ETI-EUS payerle@umd.edu
> University of Maryland (301) 405-6135
> College Park, MD 20742-4111
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by "Thomas M. Payerle" <pa...@umd.edu>.
On Mon, 21 Oct 2013, Bruce Johnson wrote:
Based on path, sounds like you have a 64 bit version of Oracle. I am
assuming that you verified that your mod_perl is a 64 bit build.
Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
My guess would be that the dependent libraries of Oracle.so are not being
picked up for some reason, despite ldd "finding" them. One thing you might try
is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
looks like should be whitespace separated), before starting apache, and see
if that gets things to work. Probably not a good long term solution (as
likely adds bloat to httpd processes), but will at least confirm that the
problem is that it is not finding those libs during the dynamic load.
>
> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
> wrote:
>
>> In message <48...@pharmacy.arizona.edu>, Bruce J
>> ohnson writes:
>>> Nope, that looks right:
>>>
>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>> x00007fb39a816000)
>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>> 1 (0x00007fb397f84000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>> 396e5c000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>
>>>
>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>> s a CGI script, either, I'd think.
>>
>> As the webserver user?
>> # su - apache
>> $ /bin/printenv
>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>
>
> # su -s /bin/sh apache
> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
> linux-vdso.so.1 => (0x00007fff047a7000)
> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>
>
> Nope.
>
> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>
> It only breaks under mod_perl.
>
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Tom Payerle
IT-ETI-EUS payerle@umd.edu
University of Maryland (301) 405-6135
College Park, MD 20742-4111
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
wrote:
> In message <48...@pharmacy.arizona.edu>, Bruce J
> ohnson writes:
>> Nope, that looks right:
>>
>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>> linux-vdso.so.1 => (0x00007fffc8980000)
>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>> x00007fb39a816000)
>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>> 1 (0x00007fb397f84000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>> 396e5c000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>
>>
>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>> s a CGI script, either, I'd think.
>
> As the webserver user?
> # su - apache
> $ /bin/printenv
> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
# su -s /bin/sh apache
sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
linux-vdso.so.1 => (0x00007fff047a7000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
/lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
Nope.
And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
It only breaks under mod_perl.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <48...@pharmacy.arizona.edu>, Bruce J
ohnson writes:
>Nope, that looks right:
>
># ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
> linux-vdso.so.1 => (0x00007fffc8980000)
> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>x00007fb39a816000)
> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>1 (0x00007fb397f84000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>396e5c000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>
>
>Also, if the linking was wrong here, it wouldn't work on the command line or a
>s a CGI script, either, I'd think.
As the webserver user?
# su - apache
$ /bin/printenv
$ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 12:57 PM, John D Groenveld <jd...@elvis.arl.psu.edu> wrote:
> In message <76...@pharmacy.arizona.edu>, Bruce J
> ohnson writes:
>> DBD::Oracle was properly compiled, else it wouldn't work on the command line,
>> either.
>
> Out of my depth with Linux, but perhaps this will help:
> $ env - /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Nope, that looks right:
# ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
linux-vdso.so.1 => (0x00007fffc8980000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007fb39a816000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007fb397f84000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb396e5c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
Also, if the linking was wrong here, it wouldn't work on the command line or as a CGI script, either, I'd think.
This is maddening.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs