I’m very happy to announce that we have released Perl Dev Kit (PDK) 9.5. PDK provides developers with essential tools for building and deploying Perl applications and includes versions of PerlApp and Filter Builder for Windows, Mac OS X, Linux and Solaris. PDK 9.5 is now compatible with ActivePerl 5.14 through 5.22.
This release of PDK includes fixes to correctly handle an issue in a core Perl module.
(TL;DR) Summary: fixing the issue
If you are building with ActivePerls 5.18 through 5.22, you should upgrade your Perl to the newest release in your version, and upgrade to PDK 9.5.0. Both upgrades are required to correctly deal with the problem.
Am I affected by the core Perl Issue?
If you are running an ActivePerl 5.16 or older, or have built your own Perl with a MicroSoft compiler; No, you are not, and you don’t have to upgrade for this issue.
If you are running ActivePerl 5.18 through 5.22, any version of Strawberry Perl, Citrus Perl, DWIM Perl, or have built your own Perl with a MinGW compiler; Yes, your Perl is affected. Some modules built for these Perls may also be affected independently.
If you are using PDK 9.3 or 9.4 with ActivePerl 5.18 through 5.22 to create any stand-alone wrapped executables; Yes, you are affected.
What are the symptoms?
Unexplained crashes. A third-party executable is always involved, but it can be nearly anything. This issue is much more likely to be triggered on systems where large blocks of memory are allocated. It is much more likely on 32-bit systems. It is somewhat more likely with embedded Perl, or Perl loaded into a system process, such as IIS.
The Technical Nitty Gritty
On x86-32 there is no native support for position-independent code (PIC). This means that shared libraries (DLLs on Windows) want to be loaded into a specific location in memory, opening up the possibility of two shared libraries wanting to be in the same place, or at least to overlap with each other, which would be bad.
There is a work-around that involves shared libraries having “relocation tables” built in that will let them be loaded into different parts of memory. However, different compilers generate these tables in different ways and depend on either special annotations in the code (__declspec(dllexport)) or special compiler switches (–base-file). This results in three possible situations: either a shared library can be built with no relocation table, one relocation table, or in the worst case, two relocation tables if both work-arounds are run on the same file during compilation.
These three situations create shared libraries that sometimes work, always work, and never work, respectively. PDK 9.5 includes fixes to handle this issue consistently so shared libraries end up with just one relocation table.
Getting PDK 9.5
Make sure to download the latest build of ActivePerl 5.18, 5.20 or 5.22 (depending on the version of ActivePerl you’re using), then download the latest PDK from here. If you already own PDK 9 and you’re looking to upgrade, go to your ActiveState Account.
