I haven't ran x86 in a long time. I don't know why the situation would
be different and allow you to change LD_LIBRARY_PATH after perl starts
though. Is it possible that derived defaults are being used rather than
your change? I imagine you also have to take in to account whether you
are using 64bit OS vs 32 bit perl, etc. etc. I've always dealt with
this issue on my Sun boxes and resorted to using a wrapper script. My
environment generally needs to be different for launching other oracle
applications, so this way I don't break other things. Doesn't this
thread touch base on the issue at hand?
http://www.nabble.com/dynaloader-issue-td5616026.html
http://www.nabble.com/dynaloader-issue-td5616026.html
Martin Gainty wrote:
Peter-
this is annoying as I have used LD_LIBRARY_PATH environment variable on other
platforms
moreover
Java
if you are going to pass jni binary folders to JVM you will need to apprise JVM
of the new folder with -DLD_LIBRARY_PATH=new_folder
-DLD_LIBRARY_PATH=$_libpatha few years back I made this very suggestion but was
informed this solution does'nt work on solaris..maybe when ellison takes over
we can get this rectified..sometimes a change in command is the only way to get
a problem fixed
Mit Freundliche Gruben
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Mon, 25 May 2009 13:09:46 +0200
From: [email protected]
To: [email protected]
Subject: LD_LIBRARY_PATH on x86_64 linux
This isn't really a DBI problem, but it hit me with DBD::Oracle, so it
may be helpful for some of you (unless I've missed something obvious, in
which case I'll just confuse everybody):
For a long time I've used a construct like this:
if (open(E, "$offl_root/dbi/env")) {
printlog("reading environment from $offl_root/dbi/env");
while (<E>) {
chomp;
my ($k, $v) = split(/=/);
$ENV{$k} = $v;
printlog("setting $k=$v");
}
}
my $dbh;
$dbh = DBI->connect($data_source, $username, $auth,
{ AutoCommit => 0,
PrintError => 1,
RaiseError => 1
}
);
to set up a suitable environment (ORACLE_HOME, NLS_LANG,
LD_LIBRARY_PATH, ...) before connecting to the database. I was aware
that this wasn't completely portable (doesn't work on Solaris), but it
worked on HP-UX and i386 Linux, and I sort of assumed that it would work
on other Linux platforms, too.
I was naive. It doesn't work on x86_64 Linux (at least not 2.6.18).
A change to LD_LIBRARY_PATH after program startup seems to be ignored
and consequently libclntsh.so.10.1 isn't found. If I set LD_LIBRARY_PATH
before invoking the perl script it works, so the workaround is obvious,
but it's ugly.
Have others noticed the same thing? Does anyone know why x86_64 differs
from i386 Linux in this regard?
hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingeprägt stehen: "Ein ewig Rätsel will ich
| | | [email protected] | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009
