Bug #21583 for Module-ScanDeps: Directly created executables not working

Wed Sep 20 11:49:36 2006 Dennis.Bjellquist [...] aig.com - Ticket created

Subject:

Directly created executables not working

Hi, I'm newbie to both perl and PAR. I'm simply trying to take a sample CPAN package and test the capability of PAR to create a perl executable in a MS Windows environment. If I am missing a step to correctly use PAR, please indicate this. Thank You. Distribution name and version: ActivePerl-5.8.8.819-MSWin32-x86-267479.msi PAR-0.952.tar.gz Crypt-RandPasswd-0.02.tar.gz Perl version: v5.8.8 Operating System vendor and version: Microsoft XP SP2 Exact cut and pasted error or warning messages: Can't locate Getopt/Long.pm in @INC (@INC contains lib CODE(0x1081d10) c:\DOCUME~1\DBJELLQU\LOCALS~1\Temp\par-DBJELLQU\cache-1155766096/inc CODE(0xfff3d8) . CODE(0xfff4f8)) at lib/Crypt/RandPasswd.pm line 2487. BEGIN failed--compilation aborted at lib/Crypt/RandPasswd.pm line 2487. Compilation failed in require at script/test.pl line 12. The shortest, clearest code you can manage to write which reproduces the bug described: pp -o test.exe test.pl (test.pl is exactly as distributed in Crypt- RandPasswd-0.02.tar.gz and does generate an .exe file) test.exe (exe produces an error message) Note: This appears to be essentially the same bug as "Directly created executables not working, but executables created through par-archives work", but I included my steps for getting this error. Sorry if I double-posted on this.

Thu Sep 21 11:11:49 2006 smueller [...] cpan.org - Correspondence added

On Mi. 20. Sep. 2006, 11:49:36, DBJELLQU wrote: Show quoted text

> Exact cut and pasted error or warning messages: > Can't locate Getopt/Long.pm in @INC (@INC contains lib CODE(0x1081d10) > c:\DOCUME~1\DBJELLQU\LOCALS~1\Temp\par-DBJELLQU\cache-1155766096/inc > CODE(0xfff3d8) . CODE(0xfff4f8)) at lib/Crypt/RandPasswd.pm line 2487. > BEGIN failed--compilation aborted at lib/Crypt/RandPasswd.pm line 2487. > Compilation failed in require at script/test.pl line 12. > > The shortest, clearest code you can manage to write which reproduces > the bug described: > > pp -o test.exe test.pl (test.pl is exactly as distributed in Crypt- > RandPasswd-0.02.tar.gz and does generate an .exe file) > test.exe (exe produces an error message)

Have you tried installing Crypt::RandPasswd first so Module::ScanDeps can scan it for dependencies? I know, it's not the answer to your question and I'm digging deeper now, but it should work when you have all necessary modules installed. By the way: If you create an intermediate .par file, it won't work without finding the module either. I can tell you a bit about the nature of the error message: When running the test.exe, the included code is extracted and the directory added to the list of module search paths. It does not search the default system search paths (on Windows at least). Something uses Getopt::Long for some reason. But that wasn't packaged. In fact the exe doesn't contain *any* modules. Perhaps because the scanning failed at loading Crypt::RandPasswd. Steffen

Thu Sep 21 11:11:51 2006 The RT System itself - Status changed from 'new' to 'open'

Thu Sep 21 15:12:43 2006 Dennis.Bjellquist [...] aig.com - Correspondence added

Subject:	RE: [rt.cpan.org #21583] Directly created executables not working
Date:	Thu, 21 Sep 2006 15:12:11 -0400
To:	bug-PAR [...] rt.cpan.org
From:	"Bjellquist, Dennis" <Dennis.Bjellquist [...] AIG.com>

Steffen - Thanks for responding quickly. Sometimes I don't even see that on pay-support. I tried to re-run the Module::ScanDeps install by entering the following from the cmd line while in the C:\Perl\cpan\build\Module-ScanDeps-0.63 directory: perl Makefile.PL nmake nmake test nmake install I tried "pp -o test.exe test.pl" again, but the results didn't change. What should I reinstall or uninstall/reinstall with PAR or ScanDeps, so that (essentially)Crypt::RandPasswd will be in place first? RandPasswd.pm contains the internal reference to Getopt::Long. Since everything uses a CPAN module, can you reproduce the same error? If not, then I need to figure out what I may have done wrong. Regards - Dennis Show quoted text

-----Original Message----- From: Steffen Müller via RT [mailto:bug-PAR@rt.cpan.org] Sent: Thursday, September 21, 2006 11:12 AM To: Dennis.Bjellquist@aig.com Cc: par@perl.org Subject: [rt.cpan.org #21583] Directly created executables not working <URL: http://rt.cpan.org/Ticket/Display.html?id=21583 > On Mi. 20. Sep. 2006, 11:49:36, DBJELLQU wrote:

> Exact cut and pasted error or warning messages: > Can't locate Getopt/Long.pm in @INC (@INC contains lib CODE(0x1081d10) > c:\DOCUME~1\DBJELLQU\LOCALS~1\Temp\par-DBJELLQU\cache-1155766096/inc > CODE(0xfff3d8) . CODE(0xfff4f8)) at lib/Crypt/RandPasswd.pm line 2487. > BEGIN failed--compilation aborted at lib/Crypt/RandPasswd.pm line 2487. > Compilation failed in require at script/test.pl line 12. > > The shortest, clearest code you can manage to write which reproduces > the bug described: > > pp -o test.exe test.pl (test.pl is exactly as distributed in Crypt- > RandPasswd-0.02.tar.gz and does generate an .exe file) test.exe (exe > produces an error message)

Have you tried installing Crypt::RandPasswd first so Module::ScanDeps can scan it for dependencies? I know, it's not the answer to your question and I'm digging deeper now, but it should work when you have all necessary modules installed. By the way: If you create an intermediate .par file, it won't work without finding the module either. I can tell you a bit about the nature of the error message: When running the test.exe, the included code is extracted and the directory added to the list of module search paths. It does not search the default system search paths (on Windows at least). Something uses Getopt::Long for some reason. But that wasn't packaged. In fact the exe doesn't contain *any* modules. Perhaps because the scanning failed at loading Crypt::RandPasswd. Steffen

Fri Sep 22 09:16:41 2006 smueller [...] cpan.org - Correspondence added

On Do. 21. Sep. 2006, 15:12:43, DBJELLQU wrote: Show quoted text

> I tried to re-run the Module::ScanDeps install by entering the following > from the cmd line while in the C:\Perl\cpan\build\Module-ScanDeps-0.63 > directory: > > perl Makefile.PL > nmake > nmake test > nmake install > > I tried "pp -o test.exe test.pl" again, but the results didn't change. > > What should I reinstall or uninstall/reinstall with PAR or ScanDeps,

so that Show quoted text

> (essentially)Crypt::RandPasswd will be in place first? > > RandPasswd.pm contains the internal reference to Getopt::Long. > > Since everything uses a CPAN module, can you reproduce the same error? > > If not, then I need to figure out what I may have done wrong.

I think you misunderstood me. Module::ScanDeps was installed correctly. The problem was the following: The Module::ScanDeps scanner did not pick up Crypt::RandPasswd because it could not find it! When I said "install it first", I meant Crypt::RandPasswd. Alternatively, add the "lib" directory to the perl @INC(lude) paths first. Now, you might rightfully point out that there is a "use lib 'lib';" in the test.pl code which should pick up the 'lib' subdirectory in @INC. But that code isn't executed by M::ScanDeps. By default, it does static scanning and avoids executing any code altogether. Optionally, you can enable compile-time scanning which would probably pick up the uninstalled Crypt::RandPasswd alright. I realize that it is bad behaviour to just ignore any files it didn't find in @INC. The files might be actual missing dependencies like in your case. Then it should warn. But more often than not, the "missing" files are actually false positives: The heuristic picked up something as a module that isn't really a module. It shouldn't warn about those. It's not possible to differentiate between the two without even more heuristics which break in even subtler ways. Hence I will add optional warnings. They will be turned on when Module::ScanDeps is used in verbose mode. (E.g. via "scandeps.pl -V") I hope this clears things up. Steffen

Fri Sep 22 09:16:44 2006 smueller [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Sep 22 11:51:59 2006 Dennis.Bjellquist [...] aig.com - Correspondence added

Subject:	RE: [rt.cpan.org #21583] Directly created executables not working
Date:	Fri, 22 Sep 2006 11:51:31 -0400
To:	bug-PAR [...] rt.cpan.org
From:	"Bjellquist, Dennis" <Dennis.Bjellquist [...] AIG.com>

Steffen - That was it - pure 'newbie' error. Apparently, I need to repeat this sequence for every CPAN module I wish to 'properly' install: Show quoted text

> perl Makefile.PL > nmake > nmake test > nmake install

Once I ran this for Crypt::RandPasswd, everything was fine. Thanks - Dennis Show quoted text

-----Original Message----- From: Steffen Müller via RT [mailto:bug-PAR@rt.cpan.org] Sent: Friday, September 22, 2006 9:17 AM To: Bjellquist, Dennis Cc: par@perl.org Subject: [rt.cpan.org #21583] Directly created executables not working <URL: http://rt.cpan.org/Ticket/Display.html?id=21583 > On Do. 21. Sep. 2006, 15:12:43, DBJELLQU wrote:

> I tried to re-run the Module::ScanDeps install by entering the > following from the cmd line while in the > C:\Perl\cpan\build\Module-ScanDeps-0.63 > directory: > > perl Makefile.PL > nmake > nmake test > nmake install > > I tried "pp -o test.exe test.pl" again, but the results didn't change. > > What should I reinstall or uninstall/reinstall with PAR or ScanDeps,

so that

> (essentially)Crypt::RandPasswd will be in place first? > > RandPasswd.pm contains the internal reference to Getopt::Long. > > Since everything uses a CPAN module, can you reproduce the same error? > > If not, then I need to figure out what I may have done wrong.

I think you misunderstood me. Module::ScanDeps was installed correctly. The problem was the following: The Module::ScanDeps scanner did not pick up Crypt::RandPasswd because it could not find it! When I said "install it first", I meant Crypt::RandPasswd. Alternatively, add the "lib" directory to the perl @INC(lude) paths first. Now, you might rightfully point out that there is a "use lib 'lib';" in the test.pl code which should pick up the 'lib' subdirectory in @INC. But that code isn't executed by M::ScanDeps. By default, it does static scanning and avoids executing any code altogether. Optionally, you can enable compile-time scanning which would probably pick up the uninstalled Crypt::RandPasswd alright. I realize that it is bad behaviour to just ignore any files it didn't find in @INC. The files might be actual missing dependencies like in your case. Then it should warn. But more often than not, the "missing" files are actually false positives: The heuristic picked up something as a module that isn't really a module. It shouldn't warn about those. It's not possible to differentiate between the two without even more heuristics which break in even subtler ways. Hence I will add optional warnings. They will be turned on when Module::ScanDeps is used in verbose mode. (E.g. via "scandeps.pl -V") I hope this clears things up. Steffen

Fri Sep 22 11:52:02 2006 The RT System itself - Status changed from 'resolved' to 'open'

Sat Sep 23 03:41:57 2006 smueller [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Sep 23 03:41:59 2006 smueller [...] cpan.org - Given to SMUELLER

Sat Sep 23 03:42:00 2006 smueller [...] cpan.org - Severity Important changed to Normal

Sat Sep 23 03:42:01 2006 smueller [...] cpan.org - Broken in 0.952 deleted

Sat Sep 23 03:42:14 2006 smueller [...] cpan.org - Queue changed from PAR to Module-ScanDeps