Hello amitsq,

I think the first step is to try to update your CPAN.

I am running on LinuxOS so I think that also on WindosOS is also:

As soon is finished.

As a second step I would try to install all the dependencies manually to minimize the possibility of an error CPAN Dependencies (when I test the link was a bit slow give it some time).

Then try to install it once more.

If you still get the error update us, maybe another monk can reproduce it.

Update: I found this similar question Newly installed package has problem with perl58.dll which seams to be the same error as you are getting. Also read this PROGRAM ABORTS LOOKING FOR PERL58.DLL WHEN 5.12.1 IS INSTALLED and this How To Fix Perl58.dll is Missing / Not Found Error Messages.

Hope this helps, BR.

If you have an old version of ActivePerl installed, then the only way to get access to ActiveState's PPM repository will be to purchase support from them. Depending on your situation, that support price tag might not be an appealing option.

Here's a few other options that might work:

• If you have a compiler and make utility that is compatible with what ActiveState used, you should be able to install directly from CPAN. (For some versions of ActivePerl, you could install MinGW and dmake from ActiveState's PPM repository. But if you don't have access, this idea might not work.)
• You could check to see if there are other PPM repositories that might have the modules that you're interested in. Unfortunately the two that I know of (the Bribes repository and syphilis' repository does not have the module listed in your OP.)
• As sweetblood suggested, you might want to consider checking out Strawberry Perl, which offers a portable version that does not need to be "installed". (Or to take it a step further, you can check out berrybrew that stevieb has been working on. It leverages portable editions of Strawberry Perl to help you "install" and manage multiple versions of Perl.)

Another idea is to check out a newer version of ActivePerl. A few months ago, ActiveState announced their intention to move away from their custom package managers for the language distributions (such as PPM for ActivePerl). (Read here for more details.)

Now, it also seems that you have a very old version of Perl, I do not know how well ActiveState would support such an old version.

I may be wrong, but I think you might have to look at the ppm command (rather than cpan) to install modules on Active State.

That's not quite true. In short, it is possible to install modules directly from CPAN using ActivePerl.

The first hurdle of using Perl on Windows is that Windows does not include a compiler (and related tools) with the OS. So ActiveState's approach was to create a repository of precompiled Perl modules that could be installed on a Windows system that didn't have the required compiler components to build directly from CPAN. The drawback was that their repositories did not include all modules in CPAN and it usually did not have the latest versions of modules (unless a module's latest version had been out for a few years with no updates). But it did get around the issue of not having a compiler.

If you had a compiler (and related tools, such as make) that was compatible with what ActiveState used to build their ActivePerl, you could use that to install modules directly from CPAN. At some point ActiveState did offer MinGW and dmake PPM modules to help with this capability (And I believe I had seen some claim that ActivePerl came with everything needed to install modules directly from CPAN, but I don't recall seeing that in my personal experience). I have used that route for 32-bit ActivePerl. I don't know all of the caveats, but I think the steps were a bit more trickier to do this with 64-bit ActivePerl. (Never tried it or researched much into it. Using 32-bit Perl was good enough for my needs at that time.)

A few months ago, ActiveState announced in a blog post that they were going to move away from maintaining their own repositories for their language distributions and would instead ensure that their distributions included the tools needed to install directly from the community repositories. For their ActivePerl distributions, that would mean support out of the box for installing modules directly from CPAN.

For comparison, the team behind Strawberry Perl took a different route to the compiler challenge on Windows. They decided to include the compiler and related tools needed to install modules directly from CPAN. And, at least with the newer versions of Strawberry Perl, they do include the cpanm utility too. And, although I personally have not used it, I believe that Strawberry Perl also includes the PPM client for those who wish to go that route for installing modules.

I actually get this in private conversations a fair bit lately. The primary reason I hear for its use when other options are being tossed around is that its due to being a corporate setting, where C-level-type folks want something that they have to pay for, because that seems more legitimate. These are organizations that often don't employ any Open Source software (that they're aware of), and a purchase constitutes quality and support.

That said, the majority of the issues crop up because those same people forgo any updates, because that actually hits their budgets, so lower-level staff have to do things like OP is trying to do, and work around these types of legacy issues, which, in (pulling random statistic out of my ass) many cases causes even worse problems in the future until eventually, something needs to be done at a very large scale to rectify all of the custom nonsense, offsetting any perceived 'value' that may have been had when signing an agreement/purchase order.

Fun stuff.

ps. I've never actually used Active State, so I can't say whether it's good or bad. That said, proprietary package manager for Perl? Yeah, no. Seems like a direct vendor lock-in for no tangible benefit at all.