Perl is the underlaying coding language that our MIDAS booking software is written in.
When it comes to developing with Perl on Windows-based systems, there are broadly two options, as Windows doesn’t natively come with Perl installed (unlike Linux/Mac systems)
These two options are:
Installing either of these products on Windows provides a Perl environment.
Here at MIDAS HQ, as we primarily develop using Windows-based machines, we need a Perl environment to develop under.
For many years, we opted for ActivePerl, but at the start of 2020 we made the switch to Strawberry Perl. You can read more about this in our earlier Strawberry Perl vs ActivePerl post.
A year and a half on, and we’re still very happy with our decision to move to Strawberry Perl.
But in some spare time recently, we thought we’d take a look at what ActiveState have been doing with their ActivePerl product since we moved away from it….
It’s all about the packages…
There are over 100,000 additional Perl “modules” (or “packages”) available to enhance the “core” functionality of Perl.
Our MIDAS software requires a handful of these additional modules in order to function.
We originally loved ActivePerl as it made it really easy for our customers (and us!) to install these modules via the “Perl Package Manager” tool (or PPM) for short.
This unique feature of ActivePerl was sadly retired by the vendor (ActiveState) by ActivePerl 5.28.
From ActivePerl 5.28 onwards, if users wanted to install additional Perl modules they were encouraged to instead sign up for an ActiveState account. They could then “build” their own custom-build of ActivePerl containing the additional packages/modules they require.
This was a far less user-friendly to install Perl modules than it was to use PPM, where modules could be installed at any time with just a couple of clicks.
Anyway, we thought we’d try using ActiveState’s platform to generate a custom-build of Perl containing all the additional modules/packages which MIDAS requires.
Here’s how we got on…
Signing up for an ActiveState account
Signing up for an ActiveState account is required if you wish to “custom build” ActivePerl with the specific modules/packages you require. That is unless you have a GitHub account (which let’s face it, most of our customers likely won’t have) in which case you can just sign-in.
Having to sign-up and create an account to build/download Perl is a bit unnecessary in our view. You can, for instance, download Strawberry Perl without any of the hassle of having to create an account first.
Anyway, we created an account and logged in…
Configuring a new ActiveState build
Creating a new ActivePerl build was relatively straight forward – there was a big “Create a New Project” button.
This then allowed us to select a language – in our case, this was Perl and a Perl version.
The two most recent options (5.34.0 and 5.32.1) were flagged as “Beta”.
We therefore chose the highest version that wasn’t flagged as “in Beta”. This was 5.32.0.
Next, we could “Add package bundles”. We didn’t want this, as we wanted to add individual packages, so we unselected all package bundles at this stage.
We then selected the operating system we wanted our custom Perl build to be for (in our case, Windows).
Next up was “Project visibility” settings:
The “Project visibility” could only be set as “Public” (unless you opt for one of ActiveState’s paid plans). Finally, we gave our project a name and hit “Create Runtime”.
Adding packages
Once the project was created, we then needed to add the 24 additional Perl modules (packages) that MIDAS requires. These could either be added one at a time via the “Add Packages” button, or imported as a list via the “Import” button.
The platform then automatically resolved additional dependencies of the 24 packages we’d added, which was useful.
One other useful feature was that the platform indicated any CVE’s (Common Vulnerabilities and Exposures) for each package we were including.
Building the new build
Once all the packages MIDAS required had been added, it was then time to “build” our custom ActivePerl environment. Building indicated that it would take up to 20 minutes to complete, and the platform displayed build progress in real-time throughout.
Sadly though, our build failed!
The packages that failed related to Perl support for MariaDB databases. MIDAS supports both MySQL and MariaDB databases, so it was kinda crucial that our Perl distribution fully supported MariaDB. Anyway, the provided build logs shed no useful light on the root cause of the build failure, nor did ActiveState’s community forums.
Trying again…
We decided to try again. We created a new project, but this time selected an earlier version of Perl (5.28.3), and added in all our required packages.
This time the build completed in 23 minutes and 35 seconds, and provided us with .exe and .msi installer links.
Testing the build
We admit, we were actually a little excited – we appeared to have a custom Windows distribution of Perl that our self-hosted customers could install on their servers, and all the modules MIDAS requires would be there right “out of the box”. Our customers wouldn’t need to separately manually install any Perl modules.
So we proceeded to install this custom distribution on a test Windows server, and all seemed to initially go ok.
Once Perl was installed, we ran our handy Server Readiness Tool. This is a free tool we provide to those interested in running MIDAS on their own server. Amongst other things, the tool checks that all necessary Perl modules are available.
To our surprise, this indicated that two modules; DBD::mysql and DBD::MariaDB appeared not to be installed. These modules allow MIDAS to communicate with its back-end database.
Trying other versions
Wondering if it may have been an issue with the .msi installer, we completely uninstalled Perl and tried again with the .exe installer link instead. This produced the same results.
We also then spent time and built identical packages on the ActiveState platform under both Perl 5.26.3 and also Perl 5.34.0.
The 5.26.3 build produced the same results as the 5.28.3 build. The 5.34.0 build just failed to build (just like the original 5.32.0 build).
We looked a little deeper into our test server’s error logs and discovered that a key component needed by the MySQL and MaraDB drivers was actually missing and hadn’t been included within the distribution.
The “workaround”
It seems like we’re not the only ones having issues using recent builds of ActivePerl built on the ActiveState platform with MySQL / MariaDB packages included. A number of people have posted with similar issues in ActiveState’s forums (like in this thread, and this thread).
The issue appears to be related to a missing MySQL “client library” .dll file that doesn’t get included with builds of ActivePerl.
Their best solution… install Strawberry Perl, grab the required “libmysql__.dll” file that gets installed with that, and copy the file over to your ActivePerl install!
So we tried this, and it did indeed resolve the issue. But just to be clear – right now…
In order for ActivePerl to work with MySQL / MariaDB databases you need to install Strawberry Perl!
Yes – seriously!!
Why would anyone want to do this? – it would just be easier to install and use Strawberry Perl and not even bother with ActivePerl!
Conclusions
We’re really saddened by the recent direction that ActiveState have moved in with ActivePerl, and their apparent lack of enthusiasm for and commitment to ensuring that it actually works with popular databases!
For over a decade, we used to exclusively recommend ActivePerl to our Windows-based customers. Last year we changed to recommending either ActivePerl or Strawberry Perl.
However, in August 2021, as things stand at the moment, we can no longer recommend ActivePerl (we’ve even now removed this recommendation from our website).
In summary…
- ActivePerl 5.32 and ActivePerl 5.34 fail to correctly build at this time, so can’t be used for MIDAS.
- ActivePerl 5.28 and 5.26 do build, but are missing a required MySQL client library. In order to use either of these builds, you’d also need to grab a .dll file from an install of Strawberry Perl.
- The last known “working” version of ActivePerl is 5.24. ActivePerl 5.24 is now 5 years old, and is no longer available for download from ActiveState’s website.
So for any self-hosted customer wishing to use install our MIDAS scheduling software on their Windows server, we suggest you avoid ActivePerl and use Strawberry Perl instead.
Alternatively, you may wish to consider our cloud-hosted solution.
UPDATE: Since originally publishing this article, ActiveState have reached out. Read more in Revisiting Active Perl… Part Two!