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)

Wednesday July 19, 2006
09:39 AM

LD_LIBRARY_PATH, part 2

[ #30343 ]

As I remarked to Uri about my LD_LIBRARY_PATH problem, the real solution is that Oracle.so needs to get built properly. Today I discovered how to do that (shortly after remarking to Uri, in fact ... writing things out online like this often helps me organize my thoughts). So here is how I did it, for my own future reference. However, DBD::Oracle should probably do all this automatically in the build process (I can see it printing out some proper directories as Makefile.PL runs, but none seem to make it into the output; furthermore, there's a routine specifically designed to detect the correct directory, and it's working right, but I can't figure out what happens between then and the output.). So I will probably next report this as a bug.

The good news is I don't have to do any re-execing. As I got this working I feared that I would still have a mess because the environment on this box naturally sets LD_LIBRARY_PATH to what I do not want it to be (and in case you are unaware, YOU SHOULD NOT DO THAT! ) and I thought that would override it even if the correct library directory was compiled into Oracle.so. But it doesn't seem to. ldd finds the right library in the right directory, and a simple DBI script now works perfectly with no monkeying around with that awful variable.

So, here are the steps:

  1. Run Makefile.PL.
  2. Hand edit Makefile and mk.pm. Look for every instance of an Oracle library directory. The directory names will include the Oracle version number at some point (10.1.0 here and now), so search for every instance of that. For any directory that includes that version number, if it includes a component named "lib" rename it to "lib32." The README.aix.txt file includes some instructions for doing this, interestingly enough, and I'd been using those, but unfortunately their shortcut doesn't get every single instance of this. And a more straightforward 1,$s/lib/lib32/g would catch instances that should not changed because they are not Oracle directories.
  3. make, make test, make install, and life is good.
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.
  • 1,$s/10.1.0\/lib/&32/g
    1,$s/10.1.0\/rdbms\/lib/&32/g
    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Another observation: use Oracle's instant client, and put it in a directory that doesn't look anything like the lib/lib32 confusion, and you'll also get around this much easier. Unfortunately, instant client appears to require setting LD_LIBRARY_PATH.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • In order to compile Oracle.so such that LD_LIBRARY_PATH is not required, rerun the gcc line that created Oracle.so and add "-lnnz10" to the end. Oracle created libclntsh.so such that it requires LD_LIBRARY_PATH in order to find libnnz10. Adding this option tells the linker to go ahead and link libnnz10 directly into Oracle.so, which enables the runtime linker to find it without LD_LIBRARY_PATH telling it where to look.

      Sigh...

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