activeperl

Final Version pairings for ActivePerl with Perl Dev Kit

Question: 

I want to upgrade ActivePerl and my Perl Dev Kit. What's available?

Answer: 

You may have already seen the announcement... Last year, ActiveState announced that the direction for the company's future will be OpenSource Languages.

http://www.activestate.com/blog/2016/11/activestate-open-source-language...
http://www.activestate.com/blog/2016/12/open-source-languages-company-up...

Proprietary tooling for certain languages is not part of the OpenSource Languages Company future. Sales of both of the Dev Kit tools sets were discontinued at the time of those announcements. New licenses for PDK and TDK will not be available as separate products.
http://www.activestate.com/perl-dev-kit

Engineering and Development time and resources were immediately priorized for updating the existing language distributions. In 2017, work is starting on the new languages. Work was stopped on PDK, and that means that there will not be a PDK 9.6.

Existing copies of PDK 9.5.1 cannot use the latest releases of ActivePerl. The 2203 and 2204 builds are not compatible, and all 5.24 versions remain incompatible with the final release of PDK 9.5.1.

2202 is the last compatible ActivePerl, except on OS X.

For OS X, the 9.5.1 release of PDK was created on OS X 10.5. Every PDK must have a 100% binary compatible ActivePerl. ActivePerls switched from building on OS X 10.5 to building on OS X 10.9 at 5.22.2.2202 and are now 64-bit only. These two factors are responsible for the unresolvable symbols error message. Since there will not be a 9.6 that is also built on OS X 10.9, the 2201 release is the last ActivePerl that is compatible.

HeartBleed vulnerability and ActivePerl

Question: 

Is my Community/Business/Enterprise Edition version of ActivePerl vulnerable to HeartBleed?

Answer: 

ActivePerl Community/Business Editions which, as shipped, are affected:
- 5.14.4.1405 - upgrade to 5.14.4.1406 (Business Edition only) or 5.16.3.1604 to fix
- 5.16.3.1603 - upgrade to 5.16.3.1604 to fix
- 5.18.1.1800 - upgrade to 5.18.2.1802 to fix
- 5.18.2.1801 - upgrade to 5.18.2.1802 to fix

Modules supplied through PPM are unaffected.
Modules compiled locally must be reviewed locally for vulnerability.

Enterprise Editions can be distinguished from Community/Business Editions by the presence of an additional fifth number before the six digit build number/version control number.
ActivePerl Enterprise Editions which, as shipped, are affected:
- 5.8.9.829.9 through 829.12
- 5.10.1.1009.9 through 1009.12
- 5.12.5.1206.2 through 1206.5
- 5.14.3.1404.2 through 1405.3
- 5.16.2.1602.2 through 1603.3

New Enterprise releases have been issued and can be located under the 2014Q1.1 folder.

ActiveState PPM Availability and the 401 error

Question: 

PPM gives me a 401 Authorization Required. Why?

Answer: 

--------
UPDATE (Oct 2016): This FAQ was originally posted in 2010. If you are running a version of ActivePerl that gets a 401 error when it contacts a Business Edition Only repository, our advice has evolved. Now, you should replace that ActivePerl.

A "401" error when contacting PPM should now be treated as a indication of obsolesence.

Later versions of ActivePerl that fully support Business Edition Licences have a more informative error message instead of the basic "401". Old ActivePerls that can only report a "401" will not support a Business Edition licence if one is installed. An ActivePerl that reports a "401" from PPM is probably not compatible with your current operating system either.

---------
Original FAQ:

The repository you are accessing contains exclusively Business Edition content. If you do not have a Business Edition license installed on the system, the PPM server will advise that you are not permitted to access the directory.

Perl versions move into Business Edition when the Perl Community is no longer actively supporting that version of Perl. ActiveState policy for PPM is that free and open access to PPM binary modules for versions that have moved entirely into Business Edition will continue for *at least* six months beyond the date at which the no Community Edition versions of that Perl are available.

All versions of Perl 5.8 and 5.10 required Business Edition licensing in 2010. ActivePerl 5.8 builds older than build 829, and ActivePerl 5.10 builds older than 1008 must use the manual download process described in this FAQ:
http://community.activestate.com/node/8128

All versions of Perl 5.12 required Business Edition licenses as of September 2012. All ActivePerl 5.12 builds can use the normal PPM client with a Business Edition license installed, or the manual download process.

ActivePerl 5.14 requires a Business Edition license as of October 2013 for access to installers. PPM access for modules other than the installers remains free as of December 2013.

ActivePerl and CVE-2015-1793

Question: 

Are ActivePerl releases affected by CVE-2015-1793?

Answer: 

No ActivePerl releases, in any product line, are affected by CVE-2015-1793.

Where can I get past versions of ActivePerl?

Question: 

Where can I get past versions of ActivePerl? Is there a ftp server for ActivePerl?

Answer: 

Recent past versions of ActiveState Community Edition products, and some other download resources like checksums and alternate installers, are available from our downloads repository via the web at:

http://downloads.activestate.com/

Version of ActiveState Products which have aged out of Community Edition are still available, but now require a Business Edition license. If you have a Business Edition license, the products to which your license applies become available from your "My Account" page on our site.
http://www.activestate.com/business-edition

There is no ftp server.

Common OS X problems

Question: 

ActivePerl isn't working on OS X. Why?

Answer: 

-Are you still getting the system version of Perl instead of ActivePerl?
You likely have not finished the installation. Read the Configuration step in the Installation Guide, which explains how to set $PATH so that ActivePerl is found ahead of the system version.
http://docs.activestate.com/activeperl/5.16/install.html#os%20x%20config...
If you don't put ActivePerl on $PATH, then you must access ActivePerl and ppm using the full directory path, /usr/local/ActivePerl-5.16/bin/perl (or equivalent for other releases).

-I set $PATH yesterday, and I'm sure I had ActivePerl working, but today it's not working.
Changes to $PATH are volatile. You have to make the changes permanent by setting up your $PATH in your .profile shell configuration file.

-I can't do that. I don't have a .profile in my home directory.
No you don't. Apple designed OS X to use GUI interfaces, and they didn't think a config file for the command line shell would be necessary. You have to manually replicate what every other flavor of Unix does; copy /etc/profile to .profile in your home directory, and make changes to your personal copy.

-I did that, but it still isn't working.
You have to restart your shell before changes to .profile get read.

-Ok, I did all that, and Perl is working every time, but PPM won't add or remove modules.
You are a normal user. ActivePerl is installed into a directory which normal users can't write. PPM needs to be run through "sudo ppm" to give it the elevated privilege to manage modules.

-Huh? I wanted to replace the Apple Perl with ActivePerl. This process doesn't do that. How can I force ActivePerl to replace the Apple version?
Don't. Some of your system tools, and quite a few other vendor products expect to find a specific version of Perl in a specific place on a specific version of OS X. Replacing the Apple Perl will break things, and it is difficult to put things back without re-installing your operating system. Apple Perl will co-exist happily with ActivePerl if the defaults in the ActivePerl installer are used. Both versions will still be usable if you supply full paths to the command.

-Can't I just edit the system default /etc/profile to put ActivePerl on $PATH first? Won't that make it the default Perl?
Yes, it will, and so will creating symbolic links in system directories that are already high on the $PATH. Either of these approaches might still break third party software and system tools if they don't use hard-coded paths to the Apple Perl. On the positive side, making ActivePerl the default Perl in one of these ways is very simple to back out if for some reason things go pear shaped.

-I did everything above, but all I get is weird crashes when I run ActivePerl.
Do you have PERL5LIB set to point at the Apple Perl? Using PERL5LIB can force Perl to load libraries which contain incompatible binaries.

-I've got PPM working, but the module I want isn't available. I tried to build it locally from the CPAN source code, but I just can't seem to set the right compiler options.
ActivePerl binaries are multi-platform. Some releases were PPC/x86, and newer releases are x86/x86_64. When you compile a module locally, the compiler will only build a single architecture binary, and no matter which platform you are on, it won't match the dual architecture of the ActivePerl binaries unless you use the Apple SDK to convert what you build to match. Using the Apple SDK is a topic outside the scope of ActivePerl support.

"Error reading from file" during installation

Question: 

When I try to run the MSI installer, I get a dialog with the message:

Error reading from file C:\Path\to\Some-installer.msi. Verify that the file exists and that you can access it.

This prevents me from installing the software. What's wrong?

Answer: 

The Windows "System" group needs to have access to the file. This problem often occurs when the msi file is saved to a folder without System group permissions and with "Inherit from parent" set.

To solve this, grant the System group Read & Execute permissions for the installer.

See also:

http://devsac.blogspot.com/2009/02/error-reading-from-file-msi-verify-th...

Perl IO redirection problems on Windows

Question: 

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

Answer: 

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 foo.pl | perl bar.pl

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

perl -S foo.pl | perl -S bar.pl

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

pl2bat foo.pl
pl2bat bar.pl

Then run them as:

a | b

This is also the case for > and <.

DST and ActivePerl

Question: 

Will ActivePerl handle the new US DST changes?

Answer: 

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:

DateTime::Timezone

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.

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

Question: 

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?

Answer: 

*******************
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