LD_LIBRARY_PATH, part 2

jdavidb on 2006-07-19T14:39:14

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.


This seems to cover it all

jdavidb on 2006-08-08T19:23:37

1,$s/10.1.0\/lib/&32/g
1,$s/10.1.0\/rdbms\/lib/&32/g

Instant client

jdavidb on 2006-08-15T15:15:30

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.

Re:Instant client

jdavidb on 2006-08-15T15:45:01

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...