http://www.perlmonks.org?node_id=28554


in reply to Re: DBI, DBD::Oracle and LD_LIBRARY_PATH
in thread DBI, DBD::Oracle and LD_LIBRARY_PATH

After much work (and tye and lhoward's assistance), here's what I've got to work:
BEGIN {
  unless ($ENV{BEGIN_BLOCK}) {
    $ENV{ORACLE_HOME}     = '/common/oracle/product/v8.1.6';
    $ENV{LD_LIBRARY_PATH} = "$ENV{ORACLE_HOME}/lib";
    $ENV{TNS_ADMIN}       = '/common/oracle/env';
    $ENV{BEGIN_BLOCK} = 1;
    exec 'env',$0,@ARGV;
  }
}

use DBI;

$dbh = DBI->connect('','scmuser/scmuser@itopstst','','Oracle');
die $DBI::errstr unless defined $dbh;

[download]
lhoward says this is a problem with the way Solaris handles locating dynamically loaded libraries. ld.so.1(1) caches the LD_LIBRARY_PATH, so any changes we make don't matter. env(1) forces this to update.

*phew*

Replies are listed 'Best First'.
Re^3: DBI, DBD::Oracle and LD_LIBRARY_PATH
by Anonymous Monk on Nov 30, 2008 at 23:25 UTC

    I ran into this problem recently on Linux. (I think it was triggered by an update of the Oracle InstantClient package; it used to run okay with caring about LD_LIBRARY_PATH. I'm not certain of that, though.)

    I ended up using the solution above, but changing the first condition from

      unless ($ENV{BEGIN_BLOCK}) {

    to

      unless (($ENV{BEGIN_BLOCK}) or $^C) {

    so that my habitual "perl -c script.pl" reflexes would work. Without that change, the BEGIN block will re-execute the script in fully-operational mode, which is almost certainly not what you want.

    (Of course, in versions of Perl that have it - certainly 5.6.0 onward, maybe later revisions of 5.005 - you should just use an INIT block instead. But that wasn't an option when the question was originally asked.)

[reply]
[d/l]
[select]
      or simply give perl the library in the location where it looks for it. Silly but easy (if you are root). ln -s $ORACLE_HOME/libnnz10.so /usr/lib/libnnz10.so
[reply]
        Yes, it's an old thread, but the problem still occurs.

        Under Solaris 10, one can add the default search-path using crle: 

        root>  crle -u -l /youroracledir/lib/instantclient_11_2

        [download]
        There are a lot of options available (32/64bit, etc.), so it's worth to study the docs before copy/pasting any example given here ;-)
[reply]
[d/l]
Re^3: DBI, DBD::Oracle and LD_LIBRARY_PATH
by Anonymous Monk on Oct 16, 2007 at 02:12 UTC
    Hi, 
    I added the same lines in my perl program . 

BEGIN {
  unless ($ENV{BEGIN_BLOCK}) {
    $ENV{ORACLE_HOME}     = '/usr/local/lib/instantclient_10_2';
    $ENV{LD_LIBRARY_PATH} = '/usr/local/lib/instantclient_10_2';
    #$ENV{TNS_ADMIN}       = '/common/oracle/env';
    $ENV{BEGIN_BLOCK} = 1;
    exec 'env',$0,@ARGV;
  }
}

I am getting the below error message
 
 env: this is not a file and directory

Please help

    [download]
    Thanks Sri
[reply]
[d/l]
Re^3: DBI, DBD::Oracle and LD_LIBRARY_PATH
by Anonymous Monk on Oct 31, 2012 at 18:22 UTC

    Thanks, this sparked a recollection and I got a solution working that didn't require exec() or messy wrappers. In fact, it is desirable in context of this code to put the "use DBD::Oracle;" in a module, so the exec was questionable for me anyway...

    Use a .conf file and ldconfig. RedHat and others support this nowadays. (Google knows more about this than I do, so I leave the research to the reader.) Now on my "standard platforms" I have a .conf file listing the various LD_LIBRARY_PATHs I use, including the standardized path to Oracle client, and did ldconfig to reload that cache, and all is right with the world. No fussing with wrappers or messy execs.

    Now if only we could prod Perl to force a reload of that cache (and subsequently its own), we wouldn't have an OS dependency...

[reply]

      Now if only we could prod Perl to force a reload of that cache (and subsequently its own), we wouldn't have an OS dependency...

      Seeing how the entire concept of LD_LIBRARY_PATH is already OS dependent and flawed, perl should stay far away from it, and let the OS manage its business

[reply]

In Section Seekers of Perl Wisdom