in reply to (tye)Re: Setting LD_LIBRARY_PATH for DynaLoader modules
in thread Setting LD_LIBRARY_PATH for DynaLoader modules

This last suggestion intrigued me, and I attempted it, but I get relocation errors. Doing a truss on a properly running script yielded no additional shared libraries, so I'm kind of stumped where to proceed next along this line. 
dl_load_file: ld.so.1: /export/home/webadmin/bin/perl: fatal: relocati
+on error: file /usr/local/opt/oracle/product/8.0.5/lib/libclntsh.so: 
+symbol slpmprodstab: referenced symbol not found at VDS/Tests/DB.pm l
+ine 29.

[download]
Attempting to load an 8.1.6 version (libclntsh.so.8.0) succeeds, but I guess Oracle.so is still expecting the older version, so I still get the 'open failed' error from install_driver(Oracle)/DynaLoader..

On a related note, I can't figure out how to get Netscape web server 3.6 to pass this LD_LIBRARY_PATH to CGI scripts! Grr.. (Update: I have since figured this out, so my problem is essentially solved.)

The exec solution isn't an option here, since this is actually a module and I'd kind of like to keep it transparent to the caller. Is there any way I can modify Oracle.so's RUN_PATH without rebuilding Oracle.so? (We resorted to some serious trickiness to get this to build, since this system doesn't have a fully copy of Oracle installed on it.)

Replies are listed 'Best First'.
Re: Re: (tye)Re: Setting LD_LIBRARY_PATH for DynaLoader modules
by BigJoe (Curate) on Jan 05, 2001 at 23:02 UTC
    What you need to do is put it in your /etc/profile directory. This is because the User that runs your CGIs should call this before it runs anything. I added these lines in my /etc/profile to make it work: 
    ORACLE_HOME="/usr/local/OraHome1"
PATH="$PATH:$ORACLE_HOME/bin:"
export ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME/lib

    [download]
    It worked fine for me after I did that.

    --BigJoe

    Learn patience, you must.
    Young PerlMonk, craves Not these things.
    Use the source Luke.
[reply]
[d/l]
      We've done that for the users, but what if a script using this module is being run in a non-interactive capacity (such as via cron or another program that does not necessarily load environment settings from /etc/profile)? The idea is to make this module as absolutely self-contained as possible, and functional with little if any change to the environment as possible.

      In this specific case, the module was being called via a CGI script under Netscape server. My solution was just to add an appropriate LD_LIBRARY_PATH as an environment variable NES passes to its CGI scripts, but I view this as a messy fix, since it doesn't work towards my goal of making the module self-contained. It will do, though, and I don't think we'll have many more (if any) issues like this to deal with in the future.

[reply]

In Section Seekers of Perl Wisdom