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.
Related
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.
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.
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.
I'm getting a Can't use an undefined value as a HASH reference error trying to call HTTP::Message::decodable() using Perl 5.10 / libwww installed on Debian Lenny OS using the aptitude package manager. I'm really stuck so would appreciate some help please.
Here's the error:
Can't use an undefined value as a HASH reference at (eval 2) line 1.
at test.pl line 4
main::__ANON__('Can\'t use an undefined value as a HASH reference at
enter code here`(eval 2)...') called at (eval 2) line 1
HTTP::Message::__ANON__() called at test.pl line 6
Here's the code:
use strict;
use HTTP::Request::Common;
use Carp;
$SIG{ __DIE__ } = sub { Carp::confess( #_ ) };
print HTTP::Message::decodable();
Looking at the changelog, it looks like HTTP::Message::decodable() was added in version 5.814. Are you sure you are reading the right documentation for your version?
Try:
perl -MHTTP::Message -e 'warn $HTTP::Message::VERSION'
.. it should return 5.814 or more...
Gavin was right - I had an old version of libwww-perl installed. I was relying on using the latest version available on Debian Lenny (assuming this was fairly up to date). Turns out the latest version available is 5.813 but I need 5.814 or more to use this function. As there's no packaged version available via aptitude I installed the latest using CPAN instead:
$ perl -MCPAN -e shell
cpan[1]> upgrade HTTP::Message
All done!
I'd like to have all the installed CPAN modules updated automatically every night, so I've placed the following command in the crontab:
#daily cpan -i $(cpanp -o | perl -lane 'print $F[3]')
However, whenever this is run I get the following error message:
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and
LINES environment variables didn't work. The resize program didn't work. at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Term/ReadKey.pm
line 362.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Term/ReadLine
/Perl.pm line 63.
What can I do to get this working?
Come back on Monday. I'll add a -u command to cpan to do that if you promise to test it for me. You'll have to get the latest cpan from App::Cpan.
Okay, don't wait until Monday. I've pushed the change to the cpan-script Github repo, and App-Cpan 1.56_15 is on its way to CPAN.
Let me know if you have any problems or the new feature doesn't do what you want.
Please use brian d foy's answer as he added a cpan option to do this
Are you trying to update the list of modules with CPAN or actually update any out of date modules (d/l, compile, install)? This could be dangerous as modules could change interface and existing scripts would fail. This error is due to CPAN trying to use Term::ReadLine and Term::ReadKey to interrogate the terminal.
If you really want to upgrade all your modules, you can use this command:
perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'
This is a small change from the command given in the documentation to interrogate CPAN for all outdated modules:
https://metacpan.org/pod/CPAN#PROGRAMMERS-INTERFACE
The COLUMNS and LINES environment variables didn't work.
Try setting the COLUMNS and LINES environment variables.
COLUMNS=80
LINES=24
#daily cpan -i $(cpanp -o | perl -lane 'print $F[3]')