I've had issues with diagnostics on machines that aren't set up perfectly - and that's without PAR. For example, installing ActiveState Perl for Windows to a network share, and then everyone copying the shared version locally (for performance reasons). (Not my design.)

What happens is that the diagnostics module will look in Config for where Perl is installed, and then look for perldiag.pod there. And that's where your trouble is. If only perldiag.pod were in the __END__ section of diagnostics.pm, PAR probably would incorporate it properly.

I know this isn't a solution - short of "don't use that module in a PAR-enabled app", I don't have one. Mostly because I don't use PAR. But perhaps that will help you track down a solution.

Thanks, this certainly helps me on my way. I don't have a lot of choice in terms of using diagnostics in the app - it's a dependency somewhere deep in the dependency tree. What I can do is change diagnostics.pm or Config.pm to either not look for perldiag.pod or to include it in the par app (and update a local Config.pm accordingly). Neither is the ideal solution, but I can stop pulling my hair out now. Thanks!

Hi rvosa,

I just installed PAR 0.94 from CPAN on a freshly installed linux x86_64. Then I tried pp with the following script:

  #!/usr/bin/perl
  use strict;
  use warnings;
  use diagnostics;
  
  print "foo\n";
[download]

And used the following command to package it:

  pp -o t -c -B t.pl
[download]

This works flawlessly and prints "foo\n".

Does this work for you? What version of Perl, PAR and Module::ScanDeps do you have? Does upgrading PAR and Module::ScanDeps to the current version help?

Also, I have to tell you that using "diagnostics" in a module (i.e. in library code) is a bad idea. One should always turn that on in the application code since it shouldn't be used in production code. (I mean, honestly, will the end user benefit from the verbosity? No.)

Steffen