in reply to Setting LD_LIBRARY_PATH for DynaLoader modules

See RE: Re: DBI, DBD::Oracle and LD_LIBRARY_PATH for a solution. You have to exec something else to flush ld's cache so that the next exec will look at the new value for LD_LIBRARY_PATH.

Also, you can perhaps link the extension with LD_RUN_PATH set to tell it where to find the shared libraries so that LD_LIBRARY_PATH will no longer be needed at run time.

You could also use low-level functions of Perl's DynaLoader to explicitly load the dynamic library before you load the DBI extension.

This post has been updated.

        - tye (but my friends call me "Tye")
  • Comment on (tye)Re: Setting LD_LIBRARY_PATH for DynaLoader modules

Replies are listed 'Best First'.
Re: (tye)Re: Setting LD_LIBRARY_PATH for DynaLoader modules
by Fastolfe (Vicar) on Jan 05, 2001 at 03:13 UTC
    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.)

[reply]
[d/l]
      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