PHP 7.4 is broken - `error while loading shared libraries: libargon2.so.1`

I have created a test repo here GitHub - convenient/travis-debug

The following .travis.yml

language: php
php: 7.4
script:
    - php --version

Yields the following error

0.01s0.02s$ phpenv global 7.4 2>/dev/null
7.4 is not pre-installed; installing
Downloading archive: https://storage.googleapis.com/travis-ci-language-archives/php/binaries/ubuntu/16.04/x86_64/php-7.4.tar.bz2
11.41s$ curl -sSf --retry 5 -o archive.tar.bz2 $archive_url && tar xjf archive.tar.bz2 --directory /
0.01s0.02s$ phpenv global 7.4
php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory
0.05s$ composer self-update
php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory
$ php --version
php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory
$ composer --version
php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory
0.05s$ php --version
php: error while loading shared libraries: libargon2.so.1: cannot open shared object file: No such file or directory
The command "php --version" exited with 127.

See Travis CI - Test and Deploy with Confidence for logs.

PHP 7.4 has 8 months left security support so many applications still run it.

What can we do to get our deployments and pipelines flowing again?

4 Likes

Same here!

@chripu If you’re lucky and your build isn’t too custom switching to dist: bionic is a quick workaround.

However that doesnt work for all of my more complex .travis.yml setups

@convenient Thanks for the advice. But then other things break. :man_shrugging: I hope someone has another solution.

@chripu Yeah it only solved for one of my projects

Travis support has got back to me with this

Hello,

Thank you for reaching out! I will happily assist you.

We have already raised this issue to related team and started working on it. For such cases using dist: bionic works as a workaround, however we will try to fix this issue on dist: xenial images as well.

Thank you for your patience I am sorry about the delay on this issue.

4 Likes

Hi, we are experiencing this issue too with “dist: xenial”. How will we know when a fix is in place?

Thank you

We are experiencing exactly the same build issues/errors. I’ve sent Travis support an email to ask them for status on this - I’m still waiting for a response.

Does anyone else have an ETA on this from Travis support?

Also running into this. Ive opened support ticket to get ETA on fix. Waiting for response.

I’ve written them another angry email asking for an ETA.

Facing the same issue since yesterday. Is there any timelines been provided by Travis.

same issue as well. Is there any work around?

Yesterday when I submitted a Support ticket with Travis, they replied back with this ‘work around’:

We have raised this case to the related team and started working on it. Could you please try with dist: bionic as a workaround for now while we fix this issue fordist: xenial image?

Other than that, I haven’t heard if this is going to be resolved anytime soon.

I changed my dist to bionic but Travis doesn’t even kick off.

This morning we experienced the same issue.

We ended up doing this:

“Builds are failing on Travis due to a missing package for php 7.4.28 on the xenial distro. For now we hardcoded a value of php 7.4.22 on the .travis.yml field. This workaround helped us build the artifacts/PRs on Travis”

We’re hoping that Travis support has a resolution soon on this.

3 Likes

Same trouble. No more way to have CTI working with PHP 7.4

Hardcoding “7.4.22” in our .travis.yml works for us - thanks for the workaround tip. Also hoping for a permanent resolution from Travis soon.

My support ticket I filed earlier today still has not been responded to.

3 Likes

Can confirm this is a workaround. Thanks!

Thanks for the workaround! Hopefully Travis sends out a permanent fix soon.

This issue broke our build processes as well, thanks for the 7.4.22 workaround — that helped temporarily resolve our issue.

Does anyone have a link to ‘xenial’ so we can follow when they will add support for 7.4.28?

Hey folks,

We have pushed a new fix for the Xenial image, hopefully, this should be resolved by now.

Thanks.