On Mon, Jul 15, 2013 at 11:42 PM, Ron Wilson <ronw.m...@gmail.com> wrote: > Finally, I tried "pp -l liblzma-5__.dll -o genuds.exe genuds.pl" This worked.
And this is the recommended way. > Then I started digging into pp and discovered ScanDeps.pm. Looking at > the code, it appears to attempt to detect shared objects, so I am > wondering why the LZMA library was not detected. It was the only one > not detected. ScanDeps only looks for "glue" shared libraries: When you wrap a C (or whatever) shared library libfoo.dll for Perl as a XS module Foo, then on the Perl side this results in files Foo.pm (Perl code) and Foo.dll (shared library) (technically there's also Foo.bs, but that's almost always an empty file). Foo.dll actually references (links to) libfoo.dll. It's called a "glue" library because it sits between the Perl and C world, typically marshalling Perl values from and to C values, adapting calling methods etc. When ScanDeps sees "use Foo ..." in your script (or a module recursively "use"d by it) it does: (1) tries to locate Foo.pm and adds it to the list of Perl sources to scan (2) checks whether Foo.pm might actually be an XS module (as described above) and tries to locate Foo.dll (and Foo.bs) It does _not_ examine Foo.dll at all. There're two reasons for this: (1) Checking a shared library for libraries it is linked to is highly OS specific - AFAIK there's no CPAN module that does that. Even if you knew the name of a dependent shared library, locating it in the file system is also highly OS specific [1]. (2) Even if you were able to detect and locate dependent shared libraries it's not clear whether they should be packed or not. On Linux or Unix machines, it's likely that they are "part of the environment" i.e. they do_not_ come with the Perl module Foo. E.g. on Linux liblzma*.so would be a system library. On Windows, it depends. [1] Locating the "glue" library Foo.dll is easy, since we know where Perl modules typically install Foo.dll (once we have located Foo.pm). But even that is only a heuristic. Cheers, Roderich
