Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/

J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Tuesday July 18, 2006
01:25 PM

LD_LIBRARY_PATH

[ #30327 ]

I hate this environment variable. It is presently necessary for me to set this in order for Oracle.so to load properly. But I can't just set $ENV{LD_LIBRARY_PATH}. The only value of LD_LIBRARY_PATH that matters is the value it had at the beginning of the process; changes to it during the execution of the process have no effect on shared object loading.

hmmm...

Update: 2006-07-19T14:40Z: Nothing that mentions LD_LIBRARY_PATH should leave out the fact that if you do a simple Google search for this variable you will learn about how it is abused as your first result, and so therefore there is no longer any excuse for the messes I continue to see with this variable. Every system administrator on the planet should be familiar with what this article has to say. Every UNIX software vendor on the planet should be familiar with what this article has to say, and those who do not are negligent. Documentation writers who continue to recommend setting this variable for the usual (wrong) purposes are negligent. If this variable has to be set in your environment 100% of the time (i.e., from a shell config file), something is most likely wrong.

I'm not sure if I find this variable set on the new system because Oracle recommended it be done, but I'm betting that's the case. Oracle is one of the few proprietary software vendors I still would choose to use on a regular basis, but this is just inexcusable. The facts on this situation have been out there for years. I'm just a lowly developer with less experience, yet somehow I seem to know more about this than people who should be well aware of it.

It bears mentioning that on the previous system, LD_LIBRARY_PATH is not set at all in the environment of my own account nor the account that runs all of our cron jobs.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • $ENV{ LD_LIBRARY_PATH } = $whatever;
    exec { $0 } $0, @ARGV

    ?

    • Yes, this is more or less the workaround I came up with. (Although I'm unfamiliar with that block syntax passed to exec and am about to go look that up and learn something new. :) ).

      It's not my preference, but it beats a wrapper all to pieces. I can write a routine which checks LD_LIBRARY_PATH, returns if it's already been modified, and then modifies it and re-execs. And then I can throw that routine into a module for every single program on this box to use. (Sigh.)

      My only fear so far is what happen

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • You could try adding the pertinent directory to /etc/ld.so.conf (assuming this is Linux; maybe on Unices as well, but I have no experience with them).

        • (After which, of course, you’ll have to run ldconfig to refresh the linker run time bindings.)

        • It's Solaris, and even if it weren't I could not do that because it would mess up many, many other apps. Everything else on this box needs the other library directory.

          Be sure to check out Why LD_LIBRARY_PATH is bad [visi.com] if you haven't already. It mentions ld.so.conf . :)

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • the libs use the env value as they see it when they start up. so if you set %ENV before you load the other libs it should work fine:

    BEGIN {
          $ENV{LD_LIBRARY_PATH} = 'path_to_lib' ;
    }

    use FooLib ;

    uri
    • Based on what I was seeing yesterday, that is not correct. Oracle.so does not load at compilation time. All I do is use DBI. If I understand correctly, DBD::Oracle is not loaded until I say DBI->connect("dbi:Oracle...").

      But just in case I was misunderstanding, I tried what you are suggesting, two ways: by putting the setting of LD_LIBRARY_PATH in a BEGIN block, as you suggested, and also by throwing 'use DBI' into a string eval, just for good measure, to make certain that the load must occur after t

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers