I have a weird issue with a script running under cron

[Bruce Johnson]

I get the following 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, <DATA> line 749.
at (eval 10) line 3
Compilation failed in require at (eval 10) line 3, <DATA> line 749.
Perhaps a required shared library or dll isn't installed where expected
at /home/allwebfiles/perl/kfs/kfsupdate.pl line 21

The script runs just fine when run interactively in a shell.

This normally means an issue with Oracle environment variables, but I wrote another script that simply lists %ENV. When run in the same crontab I get:

Environment variables
HOME = /root
LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib
LOGNAME = root
ORACLE_HOME = /usr/lib/oracle/11.2/client64
ORACLE_SID = phmweb
PATH = /usr/bin:/bin
PWD = /root
SHELL = /bin/sh
SHLVL = 1
USER = root
_ = /home/allwebfiles/perl/kfs/showenvcron.pl

These are the correct values.

So what am I missing?

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

[Bruce Ferrell]

Bruce,

The error says your script is attempting to load

/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so

for DBD::Oracle. is that the correct path for that library? it looks like you built DBD::Oracle against the Oracle occi libraries and those are often in different locations than
the regular client libs. Where is libocci.so.11.1 located? Make sure that path is available also.

[Jens Rehsack]

Hi Bruce,

Am 17.02.2014 um 19:30 schrieb Bruce Johnson <joh...@pharmacy.arizona.edu>:

> I get the following 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, <DATA> line 749.
> at (eval 10) line 3
> Compilation failed in require at (eval 10) line 3, <DATA> line 749.
> Perhaps a required shared library or dll isn't installed where expected
> at /home/allwebfiles/perl/kfs/kfsupdate.pl line 21
>
> The script runs just fine when run interactively in a shell.
>
> This normally means an issue with Oracle environment variables, but I wrote another script that simply lists %ENV. When run in the same crontab I get:
>
> Environment variables
> HOME = /root
> LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib
> LOGNAME = root
> ORACLE_HOME = /usr/lib/oracle/11.2/client64
> ORACLE_SID = phmweb
> PATH = /usr/bin:/bin
> PWD = /root
> SHELL = /bin/sh
> SHLVL = 1
> USER = root
> _ = /home/allwebfiles/perl/kfs/showenvcron.pl
>
> These are the correct values.
>
> So what am I missing?

try an ldd on /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so and any dependent
library beside standard library paths to see what might be missing. Optionally
a locate for libocci.so.11.1 might be helpful.

Cheers
--
Jens Rehsack
reh...@gmail.com

[Bruce Johnson]

On Feb 17, 2014, at 11:41 AM, Bruce Ferrell <bfer...@baywinds.org> wrote:

> Bruce,
>
> The error says your script is attempting to load
>
> /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
> for DBD::Oracle. is that the correct path for that library? it looks like you built DBD::Oracle against the Oracle occi libraries and those are often in different locations than the regular client libs. Where is libocci.so.11.1 located? Make sure that path is available also.
>

I built DBD::Oracle against this Instant client install. Both command-line and web apps run fine, it’s just this cron job.

[root@merthiolate bin]# find / -name libocci.so.11.1 -print
/usr/lib/oracle/11.2/client64/lib/libocci.so.11.1

Right where it’s supposed to be on $LD_LIBRARY_PATH

Permissions are correct as well :

-rw-r--r-- 1 root root 1971762 Sep 17 2011 /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1

This is odd…

>
> On 02/17/2014 10:30 AM, Bruce Johnson wrote:
>> I get the following 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, <DATA> line 749.
>> at (eval 10) line 3
>> Compilation failed in require at (eval 10) line 3, <DATA> line 749.
>> Perhaps a required shared library or dll isn't installed where expected
>> at /home/allwebfiles/perl/kfs/kfsupdate.pl line 21
>>
>> The script runs just fine when run interactively in a shell.
>>
>> This normally means an issue with Oracle environment variables, but I wrote another script that simply lists %ENV. When run in the same crontab I get:
>>
>> Environment variables
>> HOME = /root
>> LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib
>> LOGNAME = root
>> ORACLE_HOME = /usr/lib/oracle/11.2/client64
>> ORACLE_SID = phmweb
>> PATH = /usr/bin:/bin
>> PWD = /root
>> SHELL = /bin/sh
>> SHLVL = 1
>> USER = root
>> _ = /home/allwebfiles/perl/kfs/showenvcron.pl
>>
>> These are the correct values.
>>
>> So what am I missing?
>>
>

[Richie]

Is LD_LIBRARY_PATH exported? It's hard to see whats going on without a
full test case.

[John D Groenveld]

In message <5302803C...@triad.rr.com>, Richie writes:
>Is LD_LIBRARY_PATH exported? It's hard to see whats going on without a
>full test case.

The OP shouldn't need to set a LD_LIBRARY_PATH so long as
he built DBD::Oracle with the correct runtime link path, but
a simple shell script to see which libraries aren't resolving
would be a useful test:
#!/bin/ksh
/bin/env - /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so

John
groe...@acm.org

[Bruce Johnson]

Everything works on the command line interactively. The error only happens when the script is run via cron; however the ORACLE_HOME and LD_LIBRARY_PATH variables appear to be set correctly.

This is a fairly lengthy script that hits tables in use during working hours, yet depends on remote databases not available to me most of the nights, so it may take a few days to work through checking stuff since I only have about two hours a day when I can actually run it :-)

[L Y Lam]

Not like interactive logon, cron does not run your ".profile".
It might be crazy to ask whether you have explicitly executed your ".profile" before invoking your Perl script.

L Y

Disclaimer: This email (including any attachments) is for the use of the intended recipient only and may contain confidential information and/or copyright material. If you are not the intended recipient, please notify the sender immediately and delete this email and all copies from your system. Any unauthorized use, disclosure, reproduction, copying, distribution, or other form of unauthorized dissemination of the contents is expressly prohibited.

[Jens Rehsack]

Am 17.02.2014 um 23:43 schrieb Bruce Johnson <joh...@pharmacy.arizona.edu>:

>
> On Feb 17, 2014, at 2:48 PM, John D Groenveld <jdg...@elvis.arl.psu.edu> wrote:
>
>> In message <5302803C...@triad.rr.com>, Richie writes:
>>> Is LD_LIBRARY_PATH exported? It's hard to see whats going on without a
>>> full test case.
>>
>> The OP shouldn't need to set a LD_LIBRARY_PATH so long as
>> he built DBD::Oracle with the correct runtime link path, but
>> a simple shell script to see which libraries aren't resolving
>> would be a useful test:
>> #!/bin/ksh
>> /bin/env - /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
> Everything works on the command line interactively. The error only happens when the script is run via cron; however the ORACLE_HOME and LD_LIBRARY_PATH variables appear to be set correctly.
>
> This is a fairly lengthy script that hits tables in use during working hours, yet depends on remote databases not available to me most of the nights, so it may take a few days to work through checking stuff since I only have about two hours a day when I can actually run it :-)

Am 17.02.2014 um 19:42 schrieb Jens Rehsack <reh...@gmail.com>:

> Hi Bruce,

>
> try an ldd on /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so and any dependent
> library beside standard library paths to see what might be missing. Optionally
> a locate for libocci.so.11.1 might be helpful.

If nothing else helps, try to answer my questions, please :)

[Martin J. Evans]

On 17/02/14 18:50, Bruce Johnson wrote:
>
> On Feb 17, 2014, at 11:41 AM, Bruce Ferrell <bfer...@baywinds.org> wrote:
>
>> Bruce,
>>
>> The error says your script is attempting to load
>>
>> /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>
>> for DBD::Oracle. is that the correct path for that library? it looks like you built DBD::Oracle against the Oracle occi libraries and those are often in different locations than the regular client libs. Where is libocci.so.11.1 located? Make sure that path is available also.
>>
>
> I built DBD::Oracle against this Instant client install. Both command-line and web apps run fine, it’s just this cron job.
>
> [root@merthiolate bin]# find / -name libocci.so.11.1 -print
> /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1
>
> Right where it’s supposed to be on $LD_LIBRARY_PATH
>
> Permissions are correct as well :
>
> -rw-r--r-- 1 root root 1971762 Sep 17 2011 /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1
>
> This is odd…

Just as an aside as this caught me out yesterday.

I moved our test system to the latest instant client and DBD::Oracle.

As per usual I changed LD_LIBRARY_PATH to point to new instant client but when I ran

perl Makefile.PL

I noticed it set ORACLE_HOME to the OLD instant client path. I wondered how it had managed to do that then realised my PATH still pointed to the old instant client and it had managed to run sqlplus from there and chosen the old path.

It was easily solved by setting my PATH to the new instant client too.

Martin

[Peter J. Holzer]

On 2014-02-17 22:43:58 +0000, Bruce Johnson wrote:
> On Feb 17, 2014, at 2:48 PM, John D Groenveld <jdg...@elvis.arl.psu.edu> wrote:
> > The OP shouldn't need to set a LD_LIBRARY_PATH so long as
> > he built DBD::Oracle with the correct runtime link path, but
> > a simple shell script to see which libraries aren't resolving
> > would be a useful test:
> > #!/bin/ksh
> > /bin/env - /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
> Everything works on the command line interactively. The error only
> happens when the script is run via cron;

Yes, so obviously you should run John's little script via cron, too.
What is the result?

hp

--
_ | Peter J. Holzer | I think we need two definitions:
|_|_) | WSR - Softwaredevelopment | 1) The problem the *users* want us to solve
| | | und Projektunterstützung | 2) The problem our solution addresses.
__/ | h...@wsr.ac.at | -- Phillip Hallam-Baker on spam

[John D Groenveld]

In message <20140218110...@wsr.ac.at>, "Peter J. Holzer" writes:
>Yes, so obviously you should run John's little script via cron, too.
>What is the result?

My guess is the OP still hasn't realized that
his interactive shell environment is different then
his cron and Apache's.
<URL:http://news.gmane.org/find-root.php?message_id=201310221200.r9MC0w2D010081%40elvis.arl.psu.edu>

John
groe...@acm.org

[Bruce Johnson]

On Feb 18, 2014, at 4:02 AM, Peter J. Holzer <h...@wsr.ac.at> wrote:

> On 2014-02-17 22:43:58 +0000, Bruce Johnson wrote:
>> On Feb 17, 2014, at 2:48 PM, John D Groenveld <jdg...@elvis.arl.psu.edu> wrote:
>>> The OP shouldn't need to set a LD_LIBRARY_PATH so long as
>>> he built DBD::Oracle with the correct runtime link path, but
>>> a simple shell script to see which libraries aren't resolving
>>> would be a useful test:
>>> #!/bin/ksh
>>> /bin/env - /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>
>> Everything works on the command line interactively. The error only
>> happens when the script is run via cron;
>
> Yes, so obviously you should run John's little script via cron, too.
> What is the result?

interactively:

ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
linux-vdso.so.1 => (0x00007fffc2dd4000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007fe71e965000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007fe71c0d3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe71beab000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe71bb18000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe71b811000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe71b58d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe71b377000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fe71afaa000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe71ada6000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fe71ab8d000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007fe71a98b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe71edfd000)


Via cron (with the Oracle environment variables set as in the script in question, please read the OP!):

SHELL=/bin/sh
USER=root
LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
ORACLE_SID=PHMWEB
PATH=/usr/bin:/bin
PWD=/root
HOME=/root
SHLVL=2
LOGNAME=root
ORACLE_HOME=/usr/lib/oracle/11.2/client64


linux-vdso.so.1 => (0x00007fff33dff000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x
00007ff92b1e0000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
(0x00007ff92894e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff928726000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff928393000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff92808c000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff927e08000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff927bf2000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007ff9
27825000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007ff927621000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007ff927408000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007ff927206000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff92b678000)


No difference.

[John D Groenveld]

In message <2076EF99-9F11-4EDA...@pharmacy.arizona.edu>, Bruce J

ohnson writes:
>Via cron (with the Oracle environment variables set as in the script in questi
>on, please read the OP!):
>
>SHELL=/bin/sh
>USER=root
>LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
>ORACLE_SID=PHMWEB
>PATH=/usr/bin:/bin
>PWD=/root
>HOME=/root
>SHLVL=2
>LOGNAME=root
>ORACLE_HOME=/usr/lib/oracle/11.2/client64
>
>
> linux-vdso.so.1 => (0x00007fff33dff000)
> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>x
>00007ff92b1e0000)
> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>1
> (0x00007ff92894e000)

/tmp/test.sh
#!/bin/ksh
export ORACLE_HOME
ORACLE_HOME=/usr/lib/oracle/11.2/client64
/tmp/dbi.pl


/tmp/dbi.pl
#!/usr/local/bin/perl -w
use DBI;
my $dbh = DBI->connect( "dbi:Oracle:PHMWEB", "scott", "tiger",
{ RaiseError => 1 } );
$dbh->disconnect;


$ /bin/env -i /tmp/test.sh

John
groe...@acm.org

[Bruce Johnson]

This is functioning, since no errors came up.

One quick perl-related question, though…what environment do perl modules imported via ‘use module;’ commands have? I would think it was the environment of the importing program.

One of the use statements has an exported function that checks something in the database, and there is a db connection made if the function is called. The error line number doesn’t make sense, since the error refers to the line making my db connection in the main script, and doesn’t correspond to an existing line in the perl module, but I’ve run into oddball misdirections in perl error statements in the past.

[John D Groenveld]

In message <F99BC0A7-33D3-4501...@pharmacy.arizona.edu>, Bruce J

ohnson writes:
>This is functioning, since no errors came up.

If "env -i /path/to/shell/script" works from the command-line, then
/path/to/shell/script will work from cron.

>One quick perl-related question, though…what environment do perl modules import
>ed via ‘use module;’ commands have? I would think it was the environment of the
>importing program.

Correct, though as you learned back in October when trying to configure
your environment for Apache and modperl, you must take care to set the
environment before the module is imported.

>One of the use statements has an exported function that checks something in th
>e database, and there is a db connection made if the function is called. The e
>rror line number doesn’t make sense, since the error refers to the line making
>my db connection in the main script, and doesn’t correspond to an existing line
> in the perl module, but I’ve run into oddball misdirections in perl error stat
>ements in the past.

A short reproducable example with SCOTT's demo schema would
help me understand what you mean.

John
groe...@acm.org

[Bruce Johnson]

Well, I’ve identified my solution, but I’m not entirely certain why it’s working.

Setting the environment variables in a shell script wrapper around my perl script works. Despite %ENV being identical, when set within the perl script, I get the error, when set in the .sh wrapper it works.

It appears to be that called modules via ‘use MODULE;’ do NOT share the environment of the calling perl script?

These are my test scripts:

test.sh script

#!/bin/sh

ORACLE_HOME=/usr/lib/oracle/11.2/client64
LD_LIBRARY_PATH=$ORACLE_HOME/lib
ORACLE_SID=PHMWEB
export ORACLE_HOME LD_LIBRARY_PATH ORACLE_SID
echo "testing connection"
/home/allwebfiles/perl/kfs/test.pl
echo "Done testing connection"


test.pl script

#!/usr/bin/perl -w

$ENV{"ORACLE_HOME"}="/usr/lib/oracle/11.2/client64";
$ENV{"ORACLE_SID"}="phmweb";
$ENV{"LD_LIBRARY_PATH"}="/usr/lib/oracle/11.2/client64/lib";

use DBI;

my $login = 'scott';
my $dbpass = 'tiger';
my $dbhost='pharmacopeia.pharmacy.arizona.edu;sid=phmweb’<< substitute your own host here

print "Environment:\n";
foreach my $e (keys %ENV){
print "env var $e = $ENV{$e} \n";
}

print "\n";
print"DB test: sysdate = ";
my $dbh = DBI->connect( "dbi:Oracle:host=$dbhost", $login, $dbpass,
{ RaiseError => 1 } );
my $csr= $dbh->prepare("select sysdate from dual");
$csr->execute();
my ($out) = $csr->fetchrow();
print "$out\n";
$csr->finish();
$dbh->disconnect;


I tested this first by commenting out the $ENV{}=‘’; lines in the perl script, leaving the ones in test.sh intact:

[root@merthiolate ~]# env -i /home/allwebfiles/perl/kfs/test.sh
testing connection
Environment:
env var ORACLE_HOME = /usr/lib/oracle/11.2/client64
env var SHLVL = 1
env var LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib
env var PWD = /root
env var _ = /home/allwebfiles/perl/kfs/test.pl
env var ORACLE_SID = PHMWEB

DB test: sysdate = 19-FEB-14
Done testing connection

Then I commented out the first four lines of test.sh and uncommented the lines in test.pl

env -i /home/allwebfiles/perl/kfs/lddtest.sh
testing connection
Environment:
env var ORACLE_HOME = /usr/lib/oracle/11.2/client64
env var LD_LIBRARY_PATH = /usr/lib/oracle/11.2/client64/lib
env var SHLVL = 1
env var PWD = /root
env var _ = /home/allwebfiles/perl/kfs/test.pl
env var ORACLE_SID = phmweb

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.
at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.

Perhaps a required shared library or dll isn't installed where expected

at /home/allwebfiles/perl/kfs/test.pl line 18
DB test: sysdate = Done testing connection

It appears that DBI is NOT inheriting the environment when it’s called via ‘use DBI’ even though it’s called after I explicitly set them within the perl script.

[John D Groenveld]

In message <F661B815-79D0-4E56...@pharmacy.arizona.edu>, Bruce J

ohnson writes:
>It appears to be that called modules via ‘use MODULE;’ do NOT share the environm
>ent of the calling perl script?

No, it appears from this experiment as well as your experiment
with modperl last fall that that "use MODULE" imports MODULE
before you set the environment.

John
groe...@acm.org

[Bill Ward]

Remember that "use" is a kind of BEGIN block. You have to set the ENV variables in a BEGIN block before the "use" line.

Sent from my phone (sorry if my reply is brief, ask me again when I'm at a real keyboard)

[Peter J. Holzer]

On 2014-02-19 11:14:30 -0800, Bill Ward wrote:
> Remember that "use" is a kind of BEGIN block. You have to set the ENV
> variables in a BEGIN block before the "use" line.

Also, on several Unix-like systems (including Solaris and Linux/x86_64),
changing LD_LIBRARY_PATH while a process is running has no effect. So
this:

> On Feb 19, 2014 9:23 AM, "Bruce Johnson" <joh...@pharmacy.arizona.edu>
> wrote:

> > $ENV{"ORACLE_HOME"}="/usr/lib/oracle/11.2/client64";
> > $ENV{"ORACLE_SID"}="phmweb";
> > $ENV{"LD_LIBRARY_PATH"}="/usr/lib/oracle/11.2/client64/lib";
> >
> > use DBI;
> >

[...]

> > my $dbh = DBI->connect( "dbi:Oracle:host=$dbhost", $login, $dbpass,
> > { RaiseError => 1 } );

doesn't work even with a BEGIN {} block around the assignments to %ENV.

You have to set LD_LIBRARY_PATH in a wrapper script.

[John D Groenveld]

In message <20140220115...@wsr.ac.at>, "Peter J. Holzer" writes:
>You have to set LD_LIBRARY_PATH in a wrapper script.

The OP should link his Oracle.so with the correct rpath
so LD_LIBRARY_PATH is not required.

I prefer to put ORACLE_HOME in a wrapper so I don't have
to adjust every DBI script when it changes.

John
groe...@acm.org

[Bruce Johnson]

On Feb 20, 2014, at 4:56 AM, Peter J. Holzer <h...@wsr.ac.at> wrote:

> On 2014-02-19 11:14:30 -0800, Bill Ward wrote:
>> Remember that "use" is a kind of BEGIN block. You have to set the ENV
>> variables in a BEGIN block before the "use" line.
>
> Also, on several Unix-like systems (including Solaris and Linux/x86_64),
> changing LD_LIBRARY_PATH while a process is running has no effect. So
> this:
>
>> On Feb 19, 2014 9:23 AM, "Bruce Johnson" <joh...@pharmacy.arizona.edu>
>> wrote:
>
>>> $ENV{"ORACLE_HOME"}="/usr/lib/oracle/11.2/client64";
>>> $ENV{"ORACLE_SID"}="phmweb";
>>> $ENV{"LD_LIBRARY_PATH"}="/usr/lib/oracle/11.2/client64/lib";
>>>
>>> use DBI;
>>>
> [...]
>>> my $dbh = DBI->connect( "dbi:Oracle:host=$dbhost", $login, $dbpass,
>>> { RaiseError => 1 } );
>
> doesn't work even with a BEGIN {} block around the assignments to %ENV.
>
> You have to set LD_LIBRARY_PATH in a wrapper script.

Aaaaand I just moved this script from a Linux i686 to a Linux X86_64 system when the trouble started.


"But, soft! what light through yonder hard skull finally breaks!”

Thank you all for your patient assistance.