Hi Autrijus,
the problem seems to be a) a little bit deeper and b) a little bit more general.
I have reproduced it now with a library outside @INC :-(((.
Generally, a shared library can depend on further shared library.
In my first case, this was CtCmd.so depending on libzuba.so
(in the same directory).
In my second case, it is Zlib.so depending on libz.so (*not* in the
same directory, even not in @INC, but contained in $Config{lddlflags}
or $Config{ldflags} via "-L<path>").
At least on Solaris, the dependency checking could be done using 'ldd'.
This gives a list of dependencies - all we would need to do would be
to find out which of these are within @INC and $Config{lddlflags},
and then have Module::ScanDeps them return as dependencies to "the"
module shared library.
Further, pp needs to store them in the PAR file.
The PAR file would need an additional entry for these cross dependency
(maybe already there, in this case I have just not found the mechanism -
I am far away from being a PAR expert :-).
However, the next step to tweak would be to have PAR/Heavy.pm
calling DynaLoader::dl_load_file() of the hidden dependencies
(in the right order if we want to make this waterproof ...)
from it's bootstrap routine, *before* passing the call to
DynaLoader::bootstrap(), for loading "the" module shared library ...
I do not the sketch above very much, but from my simpleton point-of-view
it seems to be a working solution.
Ah yes, and if it should work on Solaris, what about portability?
An "alternative" approach could be to combine the shared libraries
of a module into one, but I don't know if/how this works
[sometimes dreaming of old static library times where this was a
rather easy job 8-].
Your feedback is highly appreciated ...
/Markus
--
Markus Jansen Senior IS/IT Support Engineer, EED/IT
Ericsson Eurolab Deutschland GmbH Email: [EMAIL PROTECTED]
Ericsson Allee 1 Phone: +49 2407 575 5157
52134 Herzogenrath, Germany Fax : +49 2407 575 7289
