I'm trying to install POE::Component:IRC::State but keep returning this error. I've tried googling but no solutions. Anyone know how to handle this?
install POE::Component:IRC::State
Going to read '/home/user/.cpan/Metadata'
Database was generated on Tue, 22 Jul 2014 11:41:02 GMT
Running install for module 'POE::Component::IRC::State'
Running make for B/BI/BINGOS/POE-Component-IRC-6.88.tar.gz
Checksum for /home/user/.cpan/sources/authors/id/B/BI/BINGOS/POE-Component-IRC-6.88.tar.gz ok
Scanning cache /home/user/.cpan/build for sizes
Use of uninitialized value $newdir in substitution (s///) at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/Cwd.pm line 502.
Use of uninitialized value $newdir in chdir at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/Cwd.pm line 510.
Use of chdir('') or chdir(undef) as chdir() is deprecated at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/Cwd.pm line 510.
Use of uninitialized value $newdir in pattern match (m//) at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/Cwd.pm line 525.
Use of uninitialized value $newdir in split at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/Cwd.pm line 531.
............................................................................DONE
Use of uninitialized value $_[0] in join or string at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/File/Spec/Unix.pm line 86.
Use of uninitialized value $path in pattern match (m//) at /opt/OMNIperl/lib/5.14/i86pc-solaris-thread-multi-64/File/Spec/Unix.pm line 267.
CPAN.pm: Going to build B/BI/BINGOS/POE-Component-IRC-6.88.tar.gz
Warning: No success on command[/opt/OMNIperl/bin/amd64/perl Makefile.PL]
BINGOS/POE-Component-IRC-6.88.tar.gz
/opt/OMNIperl/bin/amd64/perl Makefile.PL -- NOT OK
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
Failed during this command:
BINGOS/POE-Component-IRC-6.88.tar.gz : writemakefile NO '/opt/OMNIperl/bin/amd64/perl Makefile.PL' returned status -1
I came across something similar to this before and I believe the reason for your error, assuming you are receiving this error for other modules installations as well*, is that you need to update your current version of Perl.
From your error report it seems that you are running 5.14 but you should be running 5.20 instead. If this is a remote/personal set up, you can try upgrading your version of Perl but definitely back up everything.
If this is part of a larger system, I would highly advise contacting your system administrator and asking them to look into the problem and have them upgrade it. It is a very sensitive action and upgrading can affect a bunch of other programs you have on your servers.
Related
I'm trying to use perlbrew to install some older Perls. I believe it's failing due to the old-style version numbers. According to perlbrew available:
perl-5.14.3-RC1
perl-5.16.1
perl-5.14.2
perl-5.12.4
perl-5.10.1
perl-5.8.9
perl-5.6.2
perl5.005_04
perl5.004_05
perl5.003_07
However, when I run perlbrew install perl5.003_07, I get:
Unknown installation target "perl5.003_07", abort. Please see
`perlbrew help` for the instruction on using the install command.
If I try it by giving a direct link to the tarball, e.g. perlbrew install http://www.cpan.org/src/5.0/perl5.005_03.tar.gz, it downloads the tarball but the regex for parsing the version number fails:
Use of uninitialized value $dist_version in concatenation (.) or string at /usr/local/share/perl5/App/perlbrew.pm line 686.
Fetching perl- as /home/cpanci/perl5/perlbrew/dists/perl5.005_03.tar.gz
Use of uninitialized value $dist_version in pattern match (m//) at /usr/local/share/perl5/App/perlbrew.pm line 925.
Installing /home/cpanci/perl5/perlbrew/build/perl5.005_03 into ~/perl5/perlbrew/perls/perl-
This could take a while. You can run the following command on another shell to track the status:
tail -f ~/perl5/perlbrew/build.perl-.log
Use of uninitialized value $dist_version in pattern match (m//) at /usr/local/share/perl5/App/perlbrew.pm line 952.
Use of uninitialized value $dist_version in pattern match (m//) at /usr/local/share/perl5/App/perlbrew.pm line 969.
Installing /home/cpanci/perl5/perlbrew/build/perl5.005_03 failed. Read /home/cpanci/perl5/perlbrew/build.perl-.log to spot any
issues.
Any ideas? It's working fine for newer perls.
This is with App::perlbrew version 0.52.
I think you're stuck having to hack on perlbrew. I can get some ways by renaming the tarball perl-5.5.3.tar.gz and making a symlink in perl5/perlbrew/build like so:
lrwxrwxrwx 1 darch users 12 Oct 8 14:16 perl-5.5.3 -> perl5.005_03
, but at that point it tries to run 5.5.3's Configure with options it doesn't understand. It doesn't look to me like trying to build such old Perls with perlbrew is actually supported, for all that it does cheerfully list them.
I'm working on a Perl module using XS to bind to a C library. When I build it, I'm getting a warning message saying Use of uninitialized value $num in subtraction (-) at /usr/lib/perl5/vendor_perl/5.14.2/ExtUtils/ParseXS.pm line 1769, <GEN8> line 90.
This is triggered by the code generated by ExtUtils::Constant. Commenting out the INCLUDE: const-xs.inc line in Foo.xs removes the warning. But I don't know whether the bug is in ExtUtils::ParseXS or in ExtUtils::Constant.
I'm using ExtUtils::Constant 0.23, ExtUtils::ParseXS 3.15, Module::Build 0.38, and Perl 5.14.2.
I've managed to pare it down to a reasonably small test case that doesn't require any external C library, but it's still too large to post here. I've placed it in a GitHub repo. To reproduce the bug, clone the repo, type perl Build.PL and then ./Build. You should see:
$ perl Build.PL
Regenerating constants...
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Foo' version '0.01'
$ ./Build
Building Foo
Use of uninitialized value $num in subtraction ...
gcc ... -o lib/Foo.o lib/Foo.c
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Foo/Foo.bs')
gcc ... -o blib/arch/auto/Foo/Foo.so lib/Foo.o
You'll only see "Regenerating constants..." if you have ExtUtils::Constant installed. You shouldn't need it to reproduce the bug, because I've added the generated files to the repo.
Whatever the problem is, it doesn't seem to stop the code from working, because the included test does pass.
Update: I've reported this as RT#112776. The consensus seems to be it's a bug in ExtUtils::ParseXS, but the solution is not clear.
I am using the default perl distribution(version 5.12.3) that came bundled with os x lion. When I use the module Archive::Extract in scripts with the -W module it gives the following warnings:
Subroutine version::declare redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 139.
Subroutine version::qv redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 140.
Subroutine version::vcmp redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 142.
Subroutine version::stringify redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 145.
Subroutine version::("" redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 146.
Subroutine version::new redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 147.
Subroutine version::parse redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 148.
Subroutine UNIVERSAL::VERSION redefined at /Library/Perl/5.12/darwin-thread-multi-2level/version.pm line 194.
Name "IPC::Cmd::I18N::en::Lexicon" used only once: possible typo at /Library/Perl/Updates/5.12.3/Locale/Maketext.p\
m line 444.
Name "Archive::Extract::I18N::en::Lexicon" used only once: possible typo at /Library/Perl/Updates/5.12.3/Locale/Ma\
ketext.pm line 444.
Name "Win32::Locale::Lexicon" used only once: possible typo at /System/Library/Perl/5.12/I18N/LangTags/Detect.pm l\
ine 140.
Name "Params::Check::I18N::en::Lexicon" used only once: possible typo at /Library/Perl/Updates/5.12.3/Locale/Maket\
ext.pm line 444.
Name "Module::Load::Conditional::I18N::en::Lexicon" used only once: possible typo at /Library/Perl/Updates/5.12.3/\
Locale/Maketext.pm line 444.
I tried running upgrade in CPAN. I even deleted my .cpan directory and reconfigured my CPAN. I tested the module and it seems to work fine. But somehow I am uncomfortable with the warnings.
An other problem which made me post this question is some of my other modules are not being upgraded (via CPAN of course). This never happened to me when I was running linux.
Failed during this command:
PMQS/BerkeleyDB-0.49.tar.gz : make NO
MIKER/NetAddr-IP-4.058.tar.gz : make_test NO
DMR/DProf-19970614.tar.gz : make NO
NWCLARK/perl-5.8.6.tar.gz : make NO isa perl
JESSE/perl-5.13.9.tar.gz : make NO isa perl
SHERZODR/Class-PObject-2.17.tar.gz : make_test NO
GBARR/IO-Tty-0.04.tar.gz : writemakefile NO '/usr/bin/perl Makefile.PL' returned status 65280
DOY/Moose-2.0004.tar.gz : make_test NO
RJBS/perl-5.15.2.tar.bz2 : make NO isa perl
FLORA/perl-5.15.4.tar.gz : make NO isa perl
Should I try to clean up the default perl installation and use homebrew or macports to do a clean install? Is there something obvious I am missing which is causing all the problems?
Thanks for your help.
From perlrun...
-W Enables all warnings regardless of "no warnings" or $^W.
You got what you asked for.
You shouldn't be using -W in normal operation. Sometimes modules deliberately turn off warnings for certain things, because they know what they're doing will trigger them.
Try -w instead.
As for your other question... sometimes CPAN modules fail to install. A change of Perl version or operating system can do this. You'll have to look at the verbose output of the install attempts. Or you can look Module::Name to be dropped into a shell in the source tarball of Module::Name where you can test and debug manually.
That said, it's recommended to leave the operating system supplied Perl alone and install a fresh one for development. This allows you to make whatever changes you want, install whatever modules you want and whatever version of Perl you want without risking messing up your operating system or having your upgrades blown over in the next OS upgrade.
perlbrew is one of the best ways to handle that.
When running a perl CGI script in taint mode, I get an error of the form...
Insecure dependency in some_function while running with -T switch at (eval some_line) line some_other_line.
Compilation failed in require at my-script.cgi line 39.
BEGIN failed--compilation aborted at my-script.cgi line 39.
my-script.cgi line 39 is a use statement for a perl module which does not itself use eval or some_function, but presumably uses another library which does. The some_line and some_other_line line numbers don't seem to make sense in either my-script.cgi or the library which is 'use'd on line 39 of my-script.cgi.
Given this error, how can I track down where the taint error is occurring?
I've tried setting a new die signal handler which should print a stack trace, i.e.
$SIG{ __DIE__ } = sub { require Carp; Carp::confess(#_); };
but this seems to have no effect on the error. Perhaps this is the wrong signal to be trapping, not happening early enough, or something more complex is required.
Carp::Always works fine with exceptions raised by taint checks. Example output:
$ perl -MCarp::Always -T blah.pl
Insecure dependency in sprintf while running with -T switch at blah.pl line 6
main::foo() called at blah.pl line 8
main::bar() called at blah.pl line 10
I use Devel::SimpleTrace a lot these days for debugging and it recently helped me find a taint bug when using Archive::Zip.
However, I don't know if it would have worked in your case since it is essentially setting the same sig handler that you used.
recently I was installing some perl modules on my RHEL 5 with perl version 5.8.8 and all instalations went fine. I can see that the modules exist in the #INC but my TWiki site claims that it can't find them returning an error: Can't locate Net/LDAP.pm in #INC (a lot of paths which contain the modules) at TWiki.pm line xx. When I do perl -e 'use Net::LDAP'; it doesn't return anything which means perl can find that module. Also TWiki was configured corectly and works fine except the plugins that use specific modules I had to install, I've even added the paths to setLib.cfg just in case.
Edit:
which perl returns /usr/bin/perl
the shebang line of twiki/cgi-bin/view is #!/usr/bin/perl -wT
perl -MNet::LDAP -e 'print $INC{"Net/LDAP.pm"}, "\n";' returns:
/usr/lib/perl5/site_perl/5.8.8/Net/LDAP.pm
apache error logs show: [Tue Nov 16 10:53:47 2010] [error] [client 10.76.14.170] [Tue Nov 16 10:53:47 2010] view: INC /usr/lib/perl5/site_perl/5.8.8 at /usr/local/apache2/htdocs/twiki5_pdc/bin/view line 44. So it use's the correct path.
#INC is possibly different from your command line - either because you're using a different Perl interpreter binary, or other factors affecting #INC.
Check command line's #INC: perl -e 'print join(",", sort #INC);' - and compare to #INC printed in your Wiki's error that you mentioned.
You might have to add directories to your web server's Perl's #INC which are present in command line's ("how" depends on whether you're running under mod_perl or not).
What Apache thinks your INC path is and what your command-line Perl thinks your INC path are usually two completely different things. You may have to set the environment variable PERL5LIB in your Apache configuration.
I'm a big fan of TWiki/FOSwiki and have encountered this issue several times in the past.
Do this (it works in a good number of cases):
perldoc -l Net::LDAP
If there is POD in the file, it will point you to the .pm. Even so, if it points you to a .pod file, the .pm is usually in the same directory.
Then check that list after the #INC( and see if the path is in there. You will probably need to modify the environment that Apache runs in, because it probably will not be in there.
Since, that didn't work for you, this should:
perl -MNet::LDAP -e 'print $INC{"Net/LDAP.pm"}, "\n";'
If perl is actually loading it, that will tell you where it's loading it from.
Horses: Have you reviewed the installation guide to make sure that everything's configured correctly?
Zebras: edit bin/twiki_cgi and add right before $TWiki::engine->run():
warn "ENV $_ => $ENV{$_}" for sort keys %ENV;
warn "INC $_" for #INC;
grep your apache error log for the rows with ENV and INC. Look for ENV rows with PERL5LIB or PERLLIB. Check INC rows to make sure the directories containing your CPAN libraries are listed.
Ok the reason was most probably that I was installing the perl modules as root and they were not set executable for others so apache couldn't execute/use them.