PAR+DBD::Oracle assistance

[Viko]

Hi all,

I'm fiddling with PAR and got stuck on the following:

I'm working with 2 solaris boxes - one with Oracle 10 and one with Oracle 9. Since I want move a pp'd executable from one box to the other (don't want to worry about having identical env's), I thought of bundling Oracle libs into my PAR file like such:

pp -z 9 -v 3 -p -o MYBUNDLE.par \
-M MY_DBI_WRAPPER_MODULE \
-l libclntsh.so.10.1 \
-l libnnz10.so \
script.pl

However, when I run a script which does

use PAR 'MYBUNDLE.par';
use MY_DBI_WRAPPER_MODULE;
...

I get the following error:

install_driver(Oracle) failed: Can't load '/var/tmp/par-myuser/cache-8
+e6048b78729baef2dc5e08b6cb2d6fbf6d79bf9/08708f45.so' for module DBD::
+Oracle: ld.so.1: myscript.pl: fatal: libclntsh.so.10.1: open failed: 
+No such file or directory at /path/to/perl/lib/5.10.0/sun4-solaris/Dy
+naLoader.pm line 203.
 at /path/to/perl/lib/site_perl/5.10.0/PAR/Heavy.pm line 109
Compilation failed in require at (eval 27) line 3.
Perhaps a required shared library or dll isn't installed where expecte
+d
 at MY_DBI_WRAPPER_MODULE.pm line 83

When I check in the /var/par-user/cache directory, I do see file 08708f45.so there and has good permissions.

Any idea what I'm doing wrong or if what I want is at all possible?

Thanks in advance

[almut]

I do see file 08708f45.so there and has good permissions.

What the error message is trying to tell you is that 08708f45.so can't be loaded because the shared library libclntsh.so.10.1 (that 08708f45.so is linked against) is not found.

Okay, just a guess... but Solaris' dynamic loader (ld.so.1) is special in that you can't modify LD_LIBRARY_PATH (required to find shared libs in non-standard locations) from within an already running program — due to caching at exec time.  (Also see %ENV and DBI, for example.)

If I'm reading the PAR sources correctly, it does add its temp directory to LD_LIBRARY_PATH after unpacking, but AFAICT, it does not run the actual script via exec or system, but rather via do (which does not create a new process, so the above caching issue would apply). My assessment of the situation - based on quickly grepping through the sources - could be wrong, though...(!)

Anyhow, a possible workaround that you could try is to re-exec your script, e.g.

#!/usr/bin/perl
BEGIN {
    unless ($ENV{DONE_RESTARTING_MYSELF}) {  # avoid endless loop...
        $ENV{DONE_RESTARTING_MYSELF} = 1;
        exec $^X, $0, @ARGV;
    }
}
# ...

[Viko]

Almut,

I had seen the issue with solaris ENVs before and had found the solution here at PerlMonks. However, PAR does handle that part effectively - when running my script and printing $ENV{LD_LIBRARY_PATH}, I get the correct cache dir.

What I did find out (thanks to the replies to my question) is that PAR isn't extracting libclntsh.so.10.1 and libnnz10.so as is expected.

Is this a bug, or am I doing something weird?

Update: Looks like someone else already asked a similar question: http://www.perlmonks.org/?node_id=422008. I was expecting PAR to extract all files and file structure by itself...

[almut]

However, PAR does handle that part effectively - when running my script and printing $ENV{LD_LIBRARY_PATH}, I get the correct cache dir.

The point I was trying to make is that even though PAR is setting LD_LIBRARY_PATH to the correct directory, the dynamic loader will ignore it. This is because - on Solaris - LD_LIBRARY_PATH is parsed only once at process startup, and PAR modifies it after that. This means that if the program later tries to dynamically load other libs at runtime via dlopen (as DynaLoader does) from that non-standard location, it won't work...  unless you re-exec the program to have LD_LIBRARY_PATH be re-read.

But as it seems, you're not even at a point where this would matter :) — i.e. with libclntsh.so.10.1 and libnnz10.so not having been extracted at all...  I'm afraid I can't help with the latter problem.

[Corion]

I don't "do" Oracle, but my guess is that 08708f45.so has further external prerequisites (like the Oracle loadable libraries) which haven't been moved to the other machine. Also, you likely need to set $ENV{ORA_HOME} or whatever the Oracle environment variable is called.

[Viko]

Thanks Corion, but my whole idea is to avoid having to have Oracle installed in the other machine altogether - or at least not having to have the same oracle envs. ldd put me on the right path though. :)