Install error - "ActivePerl is not supported by my processor type"


When I try to install ActivePerl on Windows, it says it is not supported by my processor type. My system meets the ActiveState requirements. Why is it not recognized?


This message isn't an ActiveState error message. It comes from within the Microsoft Installation tool, and it's rather misleading. The processor isn't in fact the problem.

What the message really indicates is that you are attempting to install a 64-bit binary on a 32-bit version of Windows. This won't work. A 64-bit processor will run either 32-bit or 64-bit Windows, but MSI installers for 64-bit software will only install on 64-bit Windows.

Most users solve this by using the 32-bit x86 ActivePerl installer with a 32-bit Windows, however in cases where a full 64-bit x86_64 ActivePerl is necessary there is no alternative except to first upgrade to a 64-bit version of Windows.

Windows Compilers for Perl Modules


I'm trying to compile a custom module to include in a PerlApp executable. I'm using Visual Studio 2008 to compile the module. The resulting executable will not run on XP machines that do not have the compiler suite installed (a dependency seems to be generated on a C runtime library). Can you tell me what compiler toolchain I should be using to compile the module so I don't generate extra dependencies in the PerlApp executable?


For 32-bit work on 5.18 and newer:
The recommended compiler for building extensions is MinGW and dmake. There are known issues with using MicroSoft compiler toolchains, these versions are not compatible with MicroSoft Compilers.

For 32-bit work on Perl 5.16 and older:
The recommended compilers for building extensions are VC6 and MinGW. nmake from VC6, the free nmake15 download, or dmake (for MinGW) all work as the make tool.

ActivePerl was compiled with VC6 because VC6 is the last VC version that produces code that links against MSVCRT.dll, and MSVCRT.dll is the only runtime which is a standard part of Windows (and not part of a particular C compiler release). The free GCC compiler from MinGW also uses this same runtime library.

This has advantages for deployment tools like PerlApp, Perl2exe and PAR (and most of the rest of the PDK) in that they don't need to bundle MSVCR70.dll, or MSVCR71.dll, or MSVCR80.dll, or MSVCR90.dll etc into their generated executables; MSVCRT.dll is already guaranteed to be on absolutely every Windows machine.

For most extensions, there should be no problem if you build them with a later VC version, but if you use such a module with PerlApp/Perl2exe/PAR then you will need to package and auto-extract the additional runtime libraries for those compilers too. It is of course possible to mix and match multiple runtime libraries, but due to incomplete macro redefinitions in the Perl headers, that can run into problems in certain cases.

For 64-bit work on Perl 5.18 and newer:
The recommended compiler is MinGW64 and dmake. There are known issues with using MicroSoft compiler toolchains, these versions are not compatible with MicroSoft Compilers.

For 64-bit work on Perl 5.16 and older:
The recommended compiler is the VC compiler from the Windows 2003 Platform SDK. The 32-bit or 64-bit versions of nmake from this SDK, or the nmake from VC6 will work.

Once again, we used this SDK because it uses the 64-bit version of MSVCRT.dll that ships with all 64-bit versions of Windows. This has the same benefits for 64-bit users that using the standard MSVCRT.dll has for 32-bit users. As with 32-bit, you can use a newer compiler, but you will then have to include the matching C runtime (and keep in mind that Microsoft does have a right to attach conditions to redistribution of their libraries).

The make tools tend to be more of a problem with 64-bit. The old standard, nmake15, is only a 16-bit binary so it's not usable on 64-bit systems. nmake from VC6 isn't free, and the official way to get the nmake tools from the 2003 SDK is to download the entire massive SDK.

----------------- Information that applies to use with wrapping solutions like PerlApp ---------------

When building modules for use with PerlApp, your treatment of third party libraries is also very important.

Common practice when building a dll (or a sofile or dylib on other operating systems) is to dynamically link the new library for the module to the third party libraries installed on the system. This keeps the files small, avoids legal liabilities, and reduces the amount of maintenance needed on your Perl module. Most non-ActiveState PPM repositories build modules with dynamic linking. However, when dynamic linking is used, and the result is wrapped with PerlApp, the target system's dynamic loader will be called upon to find the third party library. Unless the library is present on the target system in a place where the dynamic loader can find it, your wrapped executable will fail. If the target system has an incompatible version of the third party library available to the dynamic loader, the results can be unpredictable. Binding the desired version of the third party library into your wrapped executable will have no effect, unless the dynamic loader somehow knows where that library will be extracted.

For use with PerlApp, it is desirable that modules be built with static linking. The modules in ActiveState's PPM repositories are built with static linking. Static linking embeds the third party library into the new dll, and makes the application using it truly portable. On the other hand, using static linking places legal onus on you to ensure that you have permission from the owner of the third party library to embed, and thereby redistribute, their intellectual property. In some cases, the reason a module is *not* available in PPM is that the license terms of the required third party libraries are unacceptable to us, or simply do not allow redistribution. Make sure you do your homework to understand the restrictions and conditions attached to the use of any necessary third party libraries before you create modules with static linking.

Tk compatibility problem with PPM module


I have installed the module Tk-TableMatrix 1.23 ( Installed from AS, using
AS Perl Package Manager). All my scripts using this module are broken. I
have tried to run the "demo" scripts provided in the package. And no matter
which one I run. I get the following message.
--> perl -w

Tk::TcldeclsVtab wrong size for TcldeclsVtab at
C:/PRG/Perl/lib/ line 252.

Tk::TkeventVtab wrong size for TkeventVtab at C:/PRG/Perl/lib/
line 252.


You need a version of Tk-TableMatrix 1.23 that is compiled against Tk 804.x.

When the Tk shipped with ActivePerl was updated to 804.x in the middle of the 5.8.x series, it was recognized that modules which depended on Tk would need to be recompiled. Doing so would, however, makes those modules incompatible with older releases still using Tk 802.x. Since PPM only supports one version of any given module revision per repository, all those older 5.8.x releases would have lost their PPM sources.

Improvements to the functionality of PPM are envisioned which will allow dependency based selection of module versions. For now, the workaround has been to distribute different versions of these modules with compatibility issues from different PPM repositories, some of which are not maintained by ActiveState.

Modules with dependencies on Tk802.x will continue to be available at ActiveState. Modules with dependencies on Tk804.x are available from Randy Kobes' University of Winnipeg PPM repositories:

My installation package could not be opened.


I downloaded Activeperl form your website, but when I go to start the installation process I get this error:

"This installation package could not be opened. Contact the application vendor to ensure that this is a valid installer package."

What is wrong?


This error message *always* indicates that the MSI installation package has been corrupted during the download. You will need to re-download.

It is very common to get repeated bad downloads. Please remember to flush your local cache, or switch to a different browser program. Also remember that the bad file is likely cached at your ISP, so you may have to wait a while before the bad cache is cleared.

You can verify the downloaded file against the MD5SUMS published in each download directory: ( 5.10 ) ( 5.8 )

You can get a tool to generate md5sum hashes from here:

Often you can get past a cache issue by navigating to the file differently. You might have better luck starting from here:

Perl IO redirection problems on Windows


On Unix I can run commands like " |" and have the output of be the input of This doesn't seem to work on Windows. How can I make this work?


The Windows command interpreter cmd.exe does not support IO redirection for programs started via shell associations, like those created for .pl files during the ActivePerl installation. It only works for .bat, .com, .cmd, and .exe files.

You need to write:

perl | perl

Or if the files are not in your current directory but are on the PATH:

perl -S | perl -S

Alternatively, you can wrap your .pl files into .bat scripts using pl2bat:


Then run them as:

a | b

This is also the case for > and <.

PPM Firewall problems


When I try to install a ppm package I get this error:

Downloading ActiveState Package Repository packlist...failed 500
Can't connect to (connect: Unknown error)


It looks like your local network firewall or Proxy is preventing you from connecting with our ppm servers. Instructions on how to configure Proxy authentication are available here:

Alternatively, if you have a Business Edition license, you can download zip packages for the modules you need from:

This shows the build status of each module. The column marked Logs will have a build log for the last attempt. If a module failed to build, the icon for the failed platform will have a red box around it. Like AAC-Pvoice. It fails on every platform. If you click the red box icons, you will get a report on how it failed.

If it doesn't fail to build, an icon for the platform will appear in the PPMX column. These icons are links to downloadable .ppmx files. PPMX is a newer format than the old .ppd files, but a ppmx file can be used exactly the same as the old PPD files as described in the manuals. The main advantage is that PPMX is compressed like a zip, but doesn't need to be manually unzipped before use:

Please note that some modules have dependencies and may fail to install because of this. It would be helpful to connect on an internet-enabled machine, and use ppm's 'tree' command to see what dependencies there are:

ppm> tree Date-Calc
Date-Calc 5.3
\__Bit-Vector 0.0

DST and ActivePerl


Will ActivePerl handle the new US DST changes?


ActivePerl relies on the underlying operating system for any date information. Providing the operating systems are patched to take into account the new DST laws there should be no issues.

Please note that you will want to ensure that you check any extra modules (beyond the core and enterprise edition modules that we provide) that are used are up to date.

For example:


This module needs updating, as it contains actual switchover times for various time zones. The module is updated frequently on CPAN to keep it in sync with the Olson timezone database and the latest version contains the updated rules.

What is the best version of ActivePerl to use with Windows 7?


What is the best version of ActivePerl to use with Windows 7?


The best version of ActivePerl to use on Windows 7 is always the most recent build of ActivePerl.

ActivePerl passes the same suite of tests on Windows 7 as they do on Windows XP or Vista and other supported versions of Windows.

ActivePerl's known issues on Windows Vista include:

  • PerlIS and PerlEx are installed but not automatically configured due to differences in the script extension mapping process for IIS
  • the OLE browser will not function with Internet Explorer 7

If you run into other issues, please report them at:

PPM4 fails on Windows systems for users with non-ASCII usernames


PPM4 fails on Windows systems where users have non-ASCII characters in their username and/or there are non-ASCII characters in common paths. Is there a work-around for this?


This issue has been resolved in ActivePerl 820 and higher

PPM in ActivePerl 819 on Windows fails to start up for users with non-ASCII user names. The error message displayed is something like:

  ppm gui failed: DBI connect('dbname=C:\Documents and Settings\
    \Application Data/ActiveState/ActivePerl/ppm-MSWin32-x86-multi-thread-5_8.db',
    '',...) failed: unable to open database file(1)

This is caused by limitations in Perl's handling of Unicode and we plan to address this issue in the upcoming release. The recommended workaround is to tell PPM to access its state database from a path consisting of plain ASCII characters only. It is achieved by setting the ACTIVEPERL_PPM_HOME environment variable to the name of a directory that ppm should use. For instance:

   C:\> set ACTIVEPERL_PPM_HOME=C:\Perl\Temp
   C:\> ppm

Unattended installation of ActivePerl in a custom directory on Solaris


I need to install ActivePerl in a custom directory on Solaris without any user interaction. How can I do that?


There are two ways to install ActivePerl in a custom directory on Solaris such that the installation can be run unattended.

The first is to use the "--license-accepted --prefix /path/to/install/to" arguments to the provided in the Tar/Gzip ActivePerl package:

gnutar zxf ActivePerl-solaris-package.tar.gz
cd ActivePerl-directory
sh --license-accepted --prefix /opt/ActiveState/ActivePerl

The above can be used in a shell script, for example.

Alternatively, you can make your own Solaris package. This has the benefit of registering ActivePerl with the Solaris packaging system, making upgrades easier in some cases. A good tutorial on making Solaris packages can be found here: