Below are some commonly asked questions by ActiveState users. If you have additional questions, please check the online community forums. They are regularly maintained by ActiveState staff and are contributed to by other members of the ActiveState community. For questions related to your account, contact us here.
You can do testing with a Free tier account, but the free accounts may not include some features that might be needed to test in your environment. Free accounts only have access to the most recent products, and must have unrestricted internet access. If your workplace is very secure, you may have to learn the process from a PC with unfettered access to an internet connection.
For basic testing, and for learning how to use The Platform, start with a desktop PC running Windows 11, a recent feature pack of Windows 10, or a current desktop Linux. Use a PC that has direct access to the internet, or at most is only behind a single proxy server with known credentials.
There are optional offline installers available to Enterprise Tier organizations, and to Team Tier organizations with an add-on in the contract. These must be paid for upfront, whether the runtime will work for you or not. This requirement also multiplies the impact of not knowing exactly what you need in your project, and will generally result in an update that requires months of refinements to complete, rather than weeks or days. If you can possibly test in a less restricted system, it’s highly advisable.
The long upgrade process to move a potentially insecure installation may not be the best use of resources, as it will only offer you a few months of service life (or none at all). If you are constrained by the operating systems you have in service, it is preferable if you upgrade to newer systems and then use newer software (including a newer version of Perl).
Free tier users do not have access to older versions. You might be required to start with Team, or even Enterprise Tier, to get the older version you want. Currently, no tier has access to every version of Perl shipped since the 1990s. Unfortunately, releases do eventually get old enough that they are incompatible with all currently supported versions of an operating system, or are far enough into end-of-life that we can no longer responsibly distribute them. When possible, older versions will be available at the final rollup release. If what you are looking for is not available, you may need to adjust your expectations so they are in line with what is safe, reasonable, available, and affordable.
The Platform is an online build and testing (CI) service. We no longer have a business model where the product is free/gated access to a library of never-changing downloads. Instead the Platform offers a constantly updates package library where you can choose all andonly the Perl modules you need for your project.
There isn’t a “standard” set of content (ActiveState dropped the concept of the Community Editions in 2021). Now all content is managed by the users. You can tailor your runtime to exactly what you need; no more and no less. What is available for the new releases are templates, but you will need to have a solid idea of the content that will need to be added or removed from the template to make up the project you will need.
Perl will always use OpenSSL. The core pulls it in so that it can support secure socket connections for networking. Perl never uses a third-party OpenSSL library. If you have a setup that allows Perl to find and load an incompatible third-party version, it will crash. Usually, the culprit is the order of the PATH variable
So the default behavior is for Perl to use its own OpenSSL install, but if there is an odd ordering for PATH that puts some other application (that happens to have OpenSSL) first, then that could result in an incompatible version being pulled. If you have a copy of the Microsoft Dependency Walker tool, you can usually see where a bad library is located.
5.32 and 5.36 are very similar. There’s a big discontinuity at 5.26 (the change to @INC to remove loading from the current working directory). Then at 5.32 there’s a builder change that generates all Perls as single-threaded by default. Those changes both happen between where you are now, and 5.32. OpenSSL 3 is working with the 5.34 and 5.36 on a more limited set of modules. These Crypt-OpenSSL modules are probably going to tie you to OpenSSL 1.1.1 for a while.
The Perl variables should be at, or near, the top of the variable listing, including the PERL5LIB variable. If the variable exists, look at where it’s pointed, this could impact your system setup.
Oracle Servers still set PERL5LIB, and they have their own version of Perl. One way to determine if the variable is set correctly is to see if your PERL5LIB folder has binaries in it. They may be missing or pointed to the wrong folder. And if the binaries were compiled for 5.24, they would need to be used with a 5.24.
To work with more than one project on your system, check out each project to different directories and then deploy them separately from each directory by running state shell <orgname>/<projectname>. Each shell environment is temporary, and once the working session has ended (either by typing exit into the terminal or closing the application) it will need to be re-deployed each time you work on your project.
We recommend not editing your PATH variable and instead, using the state checkout <orgname/projectname> and state use <orgname/projectname> (to set your runtime as your default installation) or state shell <orgname/projectname> (to open a secure shell in which to use your runtime) commands to interact with your Perl installation.
If you still choose to edit your PATH variable, adding your project at the \exec folder (not the \site or \bin folder) will direct your machine to the correct directory needed for your project. This will only let you add a single Perl project as your system default, as your machine will always select the first Perl addition from the top of the list and continue using that version for all projects.
Note that for Perl 5.28 and earlier, you will need to add your project at the \bin folder.
While traditionally .exe files are executables responsible for installing and running applications on your machine, the perl.exe file located in your project control folder may be different.
Some of the perl.exe files in your projects act as wrappers set up around the original perl.exe file that set up PATH and search variables to point to the correct version of the executable file that matches what is needed for your project. This is why pointing the PATH variable to the /exec folder of your project is important to ensure your projects work as intended.
If your project is unable to load, or certain .dll files fail to load, you can try adding it directly to your PATH variable. For Perl 5.28 add the (Perl)\bin folder to PATH, and for Perl 5.32 and higher, you need to also add (Perl)\exec. If that does not solve the issue try adding the folder in front of the \bin and site\bin folders.
Including a compiler would be redundant and unnecessary, as your ActiveState project has already been “compiled” by the Platform during the build process prior to you checking it out on your local system. The source code needed for your project has already been translated into machine code (or an appropriate intermediate code) by the Platform before it arrives on your local system. The interpreter in your project arrives compiled.
After your project has been built compiling your project is not necessary. Your ActiveState project has already been “compiled” by the Platform during the build process, prior to you checking it out on your local system. The interpreters in your project are already compiled.
If you need to compile your project after you have added custom content, for example, building modules from the source code on CPAN on local systems, you can use existing pre-packaged compilers (GCC, MinGW, etc.) to re-compile the project. ActiveState support for specific compilers is on a best-effort basis and, as a result, your project is not guaranteed to work with all existing compilers. If the compilers are not working within your project, you can use them in parallel to our tool, or use Strawberry Perl, Cygwin, Windows Subsystem for Linux (WSL), or Chocolatey to compile.
Details on these CVEs can be found in our documentation.