Accessing old versions of Perl in a C-language build

I co-maintain a library written in C which uses a bunch of Perl scripts during its build. We would like to test the build with the version of Perl that we document as the oldest one we support, namely 5.14.

According to, 5.14 is the version you get with dist: trusty, but that’s wrong. As best I can tell by instrumenting one of my builds, the only available version of Perl in a language: c, dist: trusty VM is 5.18:

+ ls /usr/bin/perl /usr/bin/perl5.18.2 /usr/bin/perlbug /usr/bin/perldoc /usr/bin/perlivp /usr/bin/perlthanks

total 20
drwxr-xr-x 2 travis travis 4096 Dec  5  2017 bin
drwxr-xr-x 2 travis travis 4096 Dec  5  2017 build
drwxr-xr-x 2 travis travis 4096 Dec  5  2017 dists
drwxr-xr-x 2 travis travis 4096 Dec  5  2017 etc
drwxr-xr-x 2 travis travis 4096 Dec  5  2017 perls

total 1748
-rwxr-xr-x 1 travis travis  305338 Dec  5  2017 cpanm
-rwxr-xr-x 1 travis travis 1266202 Dec  5  2017 patchperl
-rwxr-xr-x 1 travis travis  211020 Dec  5  2017 perlbrew

total 0

(quoted from the “build-aux/travis-install” section of this build log)

I tried adding perl: "5.14" to the build configuration for this job, but that gave me an error message about an unrecognized key. I presume that this knob is only supported in language:perl builds. I also tried adding perlbrew install 5.14 to my install script, but that tried to compile perl 5.14 from source, which is unacceptably slow.

How can I use one of the precompiled old perl versions that are made available to language:perl builds, in a language:c build?

N.B. The rationale for us selecting 5.14 as our oldest supported Perl is that that’s the oldest version where use feature 'unicode_strings' was fully implemented. I would consider bumping it to 5.16 if that made this task easier, but I don’t want to go to 5.18 because I do not want to introduce an accidental dependency on the hash-ordering changes in 5.18. Xenial’s 2.22 is Right Out.

You can use language: perl with an appropriate perl: and install any C compilers you need by hand (if they are not already preinstalled).

Thanks, that seems to have worked. It may have introduced other problems, though, I’ll follow up again later if I can’t sort them out.

If you insist, it should not be much work (not entirely tested) to set up the Perl environment from scratch. See

I can now say with high confidence that this does not work at all. I don’t understand why it does not work, though—the symptoms are consistent with "language:perl is just plain broken." Here’s a typical build log: Travis CI - Test and Deploy Your Code with Confidence I’ll quote the critical bit:

$ CP_VER=$(cpanm --version &); echo $CP_VER
cpanm (App::cpanminus) version 1.7044 (/home/travis/perl5/perlbrew/bin/cpanm) perl version 5.030000 (/usr/bin/perl) %Config: archname=x86_64-linux-gnu-thread-multi installsitelib=/usr/local/share/perl/5.30.0 installsitebin=/usr/local/bin installman1dir=/usr/share/man/man1 installman3dir=/usr/share/man/man3 sitearchexp=/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 sitelibexp=/usr/local/share/perl/5.30.0 vendorarch=/usr/lib/x86_64-linux-gnu/perl5/5.30 vendorlibexp=/usr/share/perl5 archlibexp=/usr/lib/x86_64-linux-gnu/perl/5.30 privlibexp=/usr/share/perl/5.30 %ENV: PERLBREW_HOME=/home/travis/.perlbrew PERLBREW_ROOT=/home/travis/perl5/perlbrew PERLBREW_SHELLRC_VERSION=0.89 @INC: FatPacked::94585902141024=HASH(0x56067f190e60) /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64/linux-gnu/perl-base
$ cpanm --quiet --installdeps --notest .
! Can't write to /usr/local/share/perl/5.30.0 and /usr/local/bin: Installing modules to /home/travis/perl5
! To turn off this warning, you have to do one of the following:
!   - run me as a root or with --sudo option (to install to /usr/local/share/perl/5.30.0 and /usr/local/bin)
!   - Configure local::lib in your existing shell to set PERL_MM_OPT etc.
!   - Install local::lib by running the following commands
!         cpanm --local-lib=~/perl5 local::lib && eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib)
! Configuring . failed. See /home/travis/.cpanm/work/1609884655.6407/build.log for details.

The command "eval cpanm --quiet --installdeps --notest . " failed. Retrying, 2 of 3.

It goes on to fail twice more in the same manner and then error out the build. This is before any of my build scripts have had a chance to execute, so I don’t see how I can fix this – or, indeed, how this could possibly work for anyone.

I kinda like this idea, but the problem is I don’t think I can do the equivalent of sh.raw archive_url_for('travis-perl-archives', version) from my own install script? I suppose I could hardcode some prefix of but that seems like asking for trouble if Travis switches storage providers…

  • 5.14 is not available for Focal as can be seen by the 404 on its download. It’s available for dist: bionic and older (as can be seen by substituting a different Ubuntu version into the download URL).
    • Strange. I see that it’s now available for Focal, too. That URL no longer returns 404. So it should work now.
  • The cpanm command is the default install: command for language: perl. Use install: skip to skip it if you don’t have your own install: section.

install: skip did get me past the cpanm errors, but now I have what may be a genuinely show-stopper problem with using language: perl: I can no longer use compiler:gcc/compiler:clang. It’s rather more important to be able to test this C program with multiple C compilers, than to test the build scripts with old perl.

Is anyone aware of an equivalent of the Travis-internal sh.raw archive_url_for('travis-perl-archives', version) that would be usable from my own install script?