I'm not very well versed in the use of PP, either :) In particular, I'm not sure how far (i.e. up to what recursion level) it would go to resolve and automagically include all secondary library dependencies, in order to create a fully self-contained package.

In your case, it looks as if the Oracle lib libclntsh.so is either missing, or - in case it is actually included - the dynamic loader is not instructed properly (via LD_LIBRARY_PATH or some such) to load the right lib.  libclntsh.so is a dependency of the DBD::Oracle module — most likely not the only one though... Running ldd on the respective .so file belonging to DBD::Oracle should show the full list of dependecies. Those would have to be included/distributed with the package (unless you can make sure by other means that they're already installed on the target system (and the versions match, etc.)).

I'm afraid I can't tell you precisely what to do to fix the issue, but hopefully this gives you some clue where to start digging in the PP docs...  Maybe you just need to somehow tell PP about the directory where the proper libclntsh.so etc. are kept (see ldd output), so it does include those libs, too (?). I would start playing with PP's option --link, or maybe -a plus manually fixing LD_LIBRARY_PATH from within your script (so the added lib files will be looked for wherever you put them...). Good luck anyway!

I am interested to see if this solved the problem or is the solution to distributing these. OP?

I think this was the root of my problem, but now I'm running into more issues with an odd configuration of this machine.

The file with secondary dependencies is Oracle.so, running ldd on it gives me the output:


        
libclntsh.so.10.1 => /apps/oracle/app/oracle/product/10g/lib32//libcln
+tsh.so.10.1
libnsl.so.1 =>   /usr/lib//libnsl.so.1
libsocket.so.1 =>        /usr/lib//libsocket.so.1
libgen.so.1 =>   /usr/lib//libgen.so.1
libdl.so.1 =>    /usr/lib//libdl.so.1
libaio.so.1 =>   /usr/lib//libaio.so.1
librt.so.1 =>    /usr/lib//librt.so.1
libkstat.so.1 =>         /usr/lib//libkstat.so.1
libm.so.1 =>     /usr/lib//libm.so.1
libthread.so.1 =>        /usr/lib//libthread.so.1
libc.so.1 =>     /usr/lib//libc.so.1
libnnz10.so => /apps/oracle/app/oracle/product/10g/lib32//libnnz10.so
libsched.so.1 =>         /usr/lib//libsched.so.1
libmp.so.2 =>    /usr/lib//libmp.so.2
libmd5.so.1 =>   /usr/lib//libmd5.so.1
/usr/platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
/usr/platform/SUNW,Sun-Fire-V490/lib/libmd5_psr.so.1
[download]

The parent poster was correct, I didn't have my LD_LIBRARY_PATH set, so I set it with
export LD_LIBRARY_PATH=/apps/oracle/app/oracle/product/10g/lib32/:/usr/lib/:/usr/platform/SUNW,Sun-Fire-V490/lib/ and tried to run pp again, this time around I get the error


install_driver(Oracle) failed: DBD::Oracle object version 1.16 does no
+t match bootstrap parameter 1.19 at /usr/local/lib/perl5/5.8.5/sun4-s
+olaris/DynaLoader.pm line 253, <STDIN> line 1.
Compilation failed in require at (eval 13) line 3, <STDIN> line 1.

 at script/billcycle.pl line 122
[download]

I've talked to the sysadmin, and apparently there is an older version of the Oracle driver (1.16, wouldn't you know) installed for an older version of Perl (5.8.3, the version I'm using is 5.8.5), that exists for some unknown reason. The headaches involved in figuring out where libraries and modules are thusly increasing exponentially.
It appears this development machine is a little FUBAR for development, and at any rate I am more than a little confused about all of it.