I'm running 32-bit Windows 7 Starter on a cheap netbook. I used to do most of my experimental coding in ActiveState Perl but switched to node.js and stopped using Perl for some time.
I had kept my Perl up to date despite not using it so had the latest version, 5.15.3 Build 1604.
Today I found something I wanted try out in Perl but ran into some problems I'd never seen before.
The perl -V command in the console would lock up without outputting anything.
I uninstalled Perl, reinstalled, did a Windows update, and rebooted my machine but now I get a system error dialog:
The dialog is followed by this error in the console:
Can't load 'C:/Perl/site/lib/auto/Win32/Win32.dll' for module Win32: load_file:The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 191.
at C:/Perl/lib/ActivePerl/Config.pm line 405.
Simple things work in perl, such as printing a literal string. ActiveState's package manager tool, ppm, seems to work fine.
I tried doing a "repair" on the installation through the control panel, but this changed nothing.
After posting the question I've noticed mentions perl512.dll!
For some reason, even though I had uninstalled and reinstalled Perl 5.15.3 something was tying it to Perl version 5.12.X ...
Since ppm was working I tried ppm upgrade Win32 and got:
Win32 0.49 (have 0.44)
Downloading Win32-0.49...done
Unpacking Win32-0.49...done
Generating HTML for Win32-0.49...done
Updating files in user area...done
2 files deleted
1 file installed
4 files updated
Perl -V now works in the console. I can't say I really understand what was going on though.
Related
I’m a mere mortal using Cygwin on Win7 and wanting to develop perl scripts using SOAP::lite. Installation instructions I found at soaplite.com directed me to start with perl –MCPAN –e shell before attempting an > install SOAP::lite
The newb in me didn’t appreciate that my windows user profile has a space character in it and the CPAN set-up seemed to go all horribly wrong around the point where the script was writing make files for local::lib, MYMETA.yml and MYYMETA.json. I got “no such file or directory” messages quoting only the portion of the path that followed the space in my user profile.
$ uname -a
CYGWIN_NT-6.1 UKLHRL00020 2.0.4(0.287/5/3) 2015-06-09 12:22 x86_64 Cygwin
$ cpan --version
Loading internal null logger. Install Log::Log4perl for logging messages
/usr/bin/cpan version 1.61 calling Getopt::Std::getopts (version 1.06 [paranoid]),
running under Perl version 5.14.4.
[Now continuing due to backward compatibility and excessive paranoia.
See ``perldoc Getopt::Std'' about $Getopt::Std::STANDARD_HELP_VERSION.]
Nothing to install!
When I ran perl –MCPAN –e shell for the first time, it did report “Warning: You do not have write permission for Perl library directories.” and I elected for the default option [local::lib] for the approach to be taken.
So what can I do next?
Looking closer at the Cygwin’s setup-x86_64.exe, a search for “cpan” lists eight packages under the perl category for perl-CPAN-* and perl-Parse-CPAN*, which are all set to “Skip”. The package perl-CPANMeta: Perl distribution CPAN-Meta is version 2.150001-1 from cygwin.mirrors.pair.com. Since this is not installed yet, but the installed Perl5 has some knowledge of an old CPAN, I need to know if it is safe to install the latest and will it work with a space in my profile? Do I need to remove the old CPAN, and how?
You probably want to update to the latest version of ExtUtils::MakeMaker, recent versions contain various fixes for paths containing spaces. This should fix these issues.
Searching the web, I have found almost no evidence that perlbrew works on cygwin. The specifics of my current issue are:
With the latest install of cygwin (which includes perl 5.14.2), I'm trying to install perl-5.14.2 using the latest perlbrew, installed from the web (not CPAN). I get a hang just after ../dist/threads-shared/t/shared_attr.t...ok is printed to build.log. This is on WinXP Pro 2002 SP3. Previous tries at using perlbrew on other builds of cygwin (which include perl 5.10.1) have also failed, but in other places.
I have posted a comment on Reini Urban's blog on blogs.perl.org and an issue/bug on github for App-perlbrew, but with no responses yet.
Is there any hope that I can get perl to build on cygwin? If not, what can I do to work around it and still use perlbrew (to unify my environments so that my cygwin environment uses perlbrew, just like my linux environment does)?
perlbrew works and perl can be built on Cygwin, with the minor annoyance that some of the unit tests hang (as you have discovered). Keep one eye on the build process output and kill the tests (usually thread related) that don't do anything for a couple of minutes using ps and kill. perlbrew should (knock on wood) run make install even if a handful of tests did not pass.
I never got perlbrew run under cygwin. But as a workaround perhaps try plenv. When I last tried it, it worked out of the box under cygwin.
A 2018 update - perlbrew works fine for me on Cygwin. However, perlbrew-installed perls will not have the patches that a system Perl has. I have a sample repo at https://github.com/cxw42/perlbrew-on-cygwin showing how I built the latest Cygwin system perl and installed it as a perlbrew perl.
In short, building Perl with prefix, site prefix, and vendor prefix set to ~/perl5/perlbrew/perls/perl-<version> will generate a Perl tree. You can drop that Perl tree into ~/perl5/perlbrew/perls/, and perlbrew will pick it up as an available Perl.
I am trying to install wxperl on strawberry. I can't install Alien::wxWidgets. I tried everything I can think of. Usually I get an error like this one:
Creating library file: ..\..\src\stc\..\..\..\lib\gcc_dll\libwxmsw28u_stc.a
compilet.exp:fake:(.edata+0x3c): undefined reference to `boot_compilet'
compilet.exp:fake:(.edata+0x40): undefined reference to `boot_compilet'
I don't know what that means. I tried with wxWidgets v 2.8.12 and 2.9.3 and various options. I started with cpanm and later evoking perl Build.PL manually with all kinds of options.
I am on Windows 7 64 bit. I tried with 5.14.2 32bit and 64bit. I am pretty sure that my path has no other perl installation than the one I currently using.
Any ideas? Thanks!
Using strawberry-perl-5.16.3.1-32bit on Windows 7.
It seems that even though the build process crashes with the error message above, Alien::wxWidgets has, in fact, been successfully made, and is ready to install.
Got the same error message building Alien::wxWidgets from SVN trunk. I ran 'build test' and the tests passed so I ran 'build install'. Wx compiled successfully, all tests passed. Padre editor compiled successfully, all tests passed, and it works well.
It is also possible to install via PPM in Strawberry perl:
ppm set repository wxPerl http://www.wxperl.co.uk/repo29 (for WxWidgets-2.9.4)
ppm install Alien::wxWidgets (version 0.61)
Unfortunately, the latest version of Padre editor requires Alien::wxWidgets 0.62, so building Alien::wxWidgets from source is necessary to make Padre from CPAN.
Alternately, you can use the Citrus Perl distribution created by Mark Dootson. One caveat, the version of Perl, 5.16.1, is not the latest, but it is more recent than DWIM Perl build of Strawberry Perl 5.14.2.1 RC.
I would recommend using the latest Strawberry Perl 5.16.3, or 5.14.4.1 for security reasons because it has a a fix for the rehashing flaw which could be used for denial of service attacks. Described here:
http://www.vuxml.org/freebsd/CVE-2013-1667.html
One idea is to install DWIM Perl, which is a Perl distribution which contains Strawberry preloaded with a whole lot of commonly used CPAN modules, and includes Alien::wxWidgets.
I'm running Windows 7 64 bit, which seems to be part of the problem. At first my cpan would hang when I would try to install CPAN from the shell prompt.
I tried restarting my computer, and a variety of attempts to use rebaseall and peflagsall from ash- even starting a new base for the dll's (the command was something suggested on a cygwin mailing list- something like rebaseall -vb 0x730000).
Should I just uninstall Cygwin and try to do a total reinstall? I have all the dependencies that cpan should need (i.e. gcc-4).
I'm getting pretty desperate here- I'm getting error messages that talk about failed dlls if I try to use modules installed from CPAN (specifically, JSON::XS).
Any help you could offer would be fantastic.
Thanks!
The complaining about missing dlls when installing is a known bug I believe, and appears for a lot of modules. Most modules are still installed and still work however. In my experience, you need to force install most modules as well, as there is almost always some test that fails.
While I personally prefer perl from the cygwin environment, there is one good reason for installing Strawberryperl; the need for 64 bit support which cygwin does not support. If you are going to work with large XML data structures using XML::Simple for instance, the 1.5-2GB that 32-bit Windows support will not take you far, and Strawberryperl will come to your rescue. And thanks to perl portability, and apart from keeping two sets of perl's installed on the same computer, the is no problem doing development using cygwin, and then running it "in production" using 64-bit Strawberryperl.
Are you installing cygwin and then building Perl on top of that? You will be far more successful if you use Strawberry Perl which comes with its own cygwin environment that will allow you to build and install most CPAN modules if you need them
I suspect the problem you're hitting is the difference between the regular shell (which will normally be bash and give you a $ prompt on Cygwin) and the cpan shell (which will give you a prompt like cpan[1]>).
In the cpan shell, install CPAN will refresh a bunch of Perl scripts from the CPAN repository. From a bash shell, install CPAN just doesn't make sense: install is a program for installing packages you've just built; it has nothing in particular to do with Perl or with how you install packages on Cygwin.
You can enter the CPAN shell by running cpan at bash shell prompt. But I don't think that's what you need. What you actually want to do is just run the following:
cpan JSON::XS
The new Mac Mini Server comes with OS X 10.6 and natively supports (comes with) two versions of Perl and Apple has included these by default for good reason.
These can be found under the following directories:
/Library/Perl/5.8.9
and
/Library/Perl/5.10.0
I also found under /Library/Perl/Updates/5.8.9 and /Library/Perl/Updates/5.10.0.
I found that I can successfully switch between perl 5.8.9 and and 5.10.0 at the console level by using Apples suggested "defaults write" command using the terminal.
For example since OS X Server 10.6 comes delivered with the default set to 5.10.0 I have successfully used the following two commands to switch to perl 5.8.9 using 32 bit and everything works as expected at the console level.
sudo defaults write /Library/Preferences/com.apple.versioner.perl Version 5.8.9
sudo defaults write com.apple.versioner.perl Prefer-32-Bit -bool yes
I was successful at installing the following desired Perl modules using the CPAN shell like so for the default version of perl 5.10.0:
sudo perl -eshell -MCPAN
install DBI
install CGI
install HTML::Template
install DBD::Pg
I used DBD:Pg to connect to the PostgreSQL database and that seems to work fine too.
However, when I attempt to switch to Perl 5.8.9 from 5.10.0 I get the following Error in Apache when attempting to use the same Perl Code.
Server error!
The server encountered an internal error and was unable to complete your request.
Error message:
Premature end of script headers: login.pl
If you think this is a server error, please contact the webmaster.
Error 500
192.168.2.100
Mon Aug 9 12:10:09 2010
APACHE/2.2.14(UNIX)mod_ssl/2.2.14 OpenSSL/0.9.81
I then decided that it might be a good idea go through the "sudo perl -eshell -MCPAN" stuff again after I switched to perl 5.8.9 by using the "default write" command however that didn't seem to help.
Does anyone have any ideas why I am getting these results?
Do you have any suggestions on a better approach without using precompiled binaries as I don't have any problem compiling from source code.
Thanks in advance.
DougPan
Tried App::perlbrew and local::lib? The first is designed for managing multiple installations of perl (though don't know if it can do existing ones) the second is for having ... more special cases of libraries installed. It would make it very easy to have 1 set of cpan libraries for each perl version and each app if you needed.