jdalbec has asked for the wisdom of the Perl Monks concerning the following question: 

t/7-check-dynaloader............................NOK 1#     Failed test
+ (t/7-check-dynaloader.t at line 27)
t/7-check-dynaloader............................NOK 2#     Failed test
+ (t/7-check-dynaloader.t at line 32)
#          got: undef
#     expected: '/usr/lib/perl5/5.8.0/i386-linux-thread-multi/'
# Looks like you failed 2 tests of 2.
t/7-check-dynaloader............................dubious
        Test returned status 2 (wstat 512, 0x200)
Scalar found where operator expected at (eval 158) line 1, near "'int'
+  $__val"
        (Missing operator before   $__val?)
DIED. FAILED tests 1-2
        Failed 2/2 tests, 0.00% okay

[download]
Any ideas? I get this error with 0.83 and 0.84.

Update: Actually I think I have an XY problem here. I was originally trying to build perl-ldap using cpan2rpm and it was hanging. I looked at the script that hung and guessed (wrongly) that I needed to install Module::Install because the script started with use inc::Module::Install;. That's how I got started trying to install Module::ScanDeps.

The cause of the hang was that cpan2rpm doesn't play nice with Module::Install's auto_install_now() because Makefile.PL is run in the background. In my environment (VMware host-only network w/o Internet connection) auto_install_now() goes into an infinite loop because I don't have CPAN set up and it keeps asking for a MIRRORED.BY URL and getting EOF. I'm using cpanflute2 from RPM::Specfile now and it doesn't have that problem. Is that the preferred tool for converting Perl modules to RPMs?

I was getting a lot of dependency failures trying to install cpanflute2 packages until I added the "--noperlreqs" option. Now I still get dependency failures on perl(perl). Is there a way to turn that off also? I sent a patch to the RPM::Specfile maintainer to create dependencies on perl instead of perl(perl).

perl 5.8 taints $0??? OK, I can handle that with Cwd::abs_path() and a regex. Confusing if you're not expecting it, though.

Replies are listed 'Best First'.
Re: Module::ScanDeps test failure
by syphilis (Archbishop) on May 15, 2008 at 02:31 UTC
    Looks like the test script expects to find the Cwd shared lib, but that file doesn't exist with pre-5.8 perls. There's 3 similar failures for 0.84 reported at http://cpantesters.perl.org/show/Module-ScanDeps.html#Module-ScanDeps-0.84.

    One of those failures relates to perl 5.8.1 (where, presumably, Cwd.so does exist). However, for that particular perl, $Config::Config{dlext} is set to "bundle", so I'm speculating that the problem there is that Cwd.bundle doesn't exist. (But that's Darwin - and I don't know anything about the bizarre things that Darwin does.)

    What does your perl -V produce ?

    Cheers,
    Rob
[reply]
[d/l]
      Cwd.so is at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/auto/Cwd/Cwd.so
      Read more... (5 kB)
[reply]
[d/l]
[select]
Re: Module::ScanDeps test failure
by Anonymous Monk on May 15, 2008 at 03:06 UTC
    Strange. I've been testing the module for some time now, but I'm getting a lot more test failures; however, the module works. Try downloading the source, switch to the test directory, then run HARNESS_PERL_SWITCHES="-MDevel::Cover" runprove -v. When that's done, run cover.
[reply]
[d/l]
[select]
[reply]
[d/l]
Re: Module::ScanDeps test failure
by DrHyde (Prior) on May 15, 2008 at 10:06 UTC
    Have you tried contacting the author of the module?
[reply]
Re: Module::ScanDeps test failure
by andreas1234567 (Vicar) on May 16, 2008 at 09:02 UTC
    What does this return? 
    use strict;
use warnings;
use Data::Dumper;
use Module::ScanDeps;
my $rv = scan_deps_runtime(
            files   => [ 't/data/check-dynaloader/Bar.pm' ],
            recurse => 1,
            compile => 1,
         );
print Dumper($rv);
__END__

    [download]
    --
    No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
[reply]
[d/l]
[reply]
[d/l]

Back to Seekers of Perl Wisdom