in reply to Re: CPAN Installation of Perl Packages Fails
in thread CPAN Installation of Perl Packages Fails
If you want more specific advice on how to fix these problems, then please let us know which operating system you are running and which version of perl you are running.
To get information about perl:
perl -vTo get much more information about perl:
perl -VTo get information about the operating system:
uname -aIn case of Linux, also try:
ls /etc/*version*and if that lists a file, show its content:
cat /etc/some-linux-distro-name-versionAlexander
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: CPAN Installation of Perl Packages Fails
by m_jaser (Novice) on Jun 22, 2017 at 15:40 UTC | |
Thanks a lot for the replies...! Here are the details of the system i'm using:
| [reply] [d/l] [select] |
by afoken (Chancellor) on Jun 22, 2017 at 20:14 UTC | |
So you are using Windows 7, on top of that a 32 bit(?) cygwin, and on top of that, a perl from somewhere unknown, maybe included with cygwin, maybe ripped out of cygwin. I guess cygwin should come with a C compiler, but it is also possible to install only parts of cygwin, and so get a system without a working compiler. If you don't explicitly need cygwin, and use it only to run perl, get rid of it and use Strawberry Perl instead. It comes preconfigured with some useful non-core packages (list hidden in the release notes). The cpan tool is also preconfigured, and of course, you get a complete build environment based on gcc, mingw, dmake (or gmake in newer versions). Installing modules is just cpan install What::Ever, as if you were using a proper unix operating system. Yes, some people may recommend ActivePerl. Once, it was the only sane way to get Perl running on Windows. But: It has its own, strange package manager for precompiled packages. A working build environment was only recently added as an optional package. Before that, you had to hunt for matching binary packages even if cpan had all the sources you needed. Frankly, Strawberry has made ActivePerl quite obsolete. Yes, it has some obscure tools that can generate exe files from perl scripts (no, they don't help protecting your code), IIRC, and some other exotic tools nobody really needs. I really prefer Strawberry. Once installed (or unpacked, if you use the Portable edition), it looks and feels like Perl on unix, except for that DOS-style C:\> prompt. And you don't have to pay a license fee of $1200+ per instance and year to get support. Heck, I've even installed Strawberry just to compile C programs for Windows. Coming back to cygwin: cygwin uses a DLL (cygwin1.dll) shared by all cygwin programs, it shares memory among all of those programs, and its intended use is to simulate POSIX features not available in Windows. Think of it as a mini-kernel running in user space on top of Windows. Of course, this weakens the boundary between cygwin programs, and IIRC, this has lead to security problems. Or at least, it could. One buggy program that overwrites the shared data and all programs using cywin suffer. Also, updating that DLL is not easy, you have to terminate all cygwin programs. Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-) | [reply] [d/l] [select] |
by dasgar (Priest) on Jun 22, 2017 at 21:24 UTC | |
I agree with you about preferring Strawberry Perl over ActivePerl. However, you can use PPM to install MinGW and dmake for ActivePerl so that you can install directly from CPAN. Also, according to this blog post, it looks like ActiveState has decided to start moving away from using their own package managers for their distributions of programming languages and will rely more on the community package repository for each programming language. For ActivePerl, that means support for install modules directly from CPAN. | [reply] |
by afoken (Chancellor) on Jun 23, 2017 at 06:21 UTC |