Amazon Linux architecture not being correctly detected

[derrickschoen]

Summary

On 64-bit Linux, PIE detects the architecture as x86 instead of x86_64, causing pre-packaged-binary asset lookup to fail even when correctly named x86_64 assets exist in the release.

Root cause

In src/Platform/TargetPlatform.php lines 73-78:

if (
    preg_match('/Architecture([ =>\t]*)(x[0-9]*)/', $phpinfo, $m)
    && array_key_exists(2, $m)
    && $m[2] !== ''
) {
    $architecture = Architecture::parseArchitecture($m[2]);
}

The regex x[0-9]* matches only digits after x. When phpinfo() reports Architecture => x86_64, the capture group $m[2] is x86 because the underscore in x86_64 is not matched by [0-9]*. This value is then passed to parseArchitecture("x86") which returns Architecture::x86 (the default case).

This overrides the correct Architecture::x86_64 that was already determined two lines above via PHP_INT_SIZE.

Reproduction

System: Amazon Linux 2023, PHP 8.5.1 NTS, uname -m reports x86_64, PHP_INT_SIZE is 8.

$ php -i | grep Architecture
Architecture => x86_64

$ pie install valkey-io/valkey-glide-php:1.1.0 -vvv
Target PHP installation: 8.5.1 nts, on Linux/OSX/etc x86 (from /usr/bin/php)
Trying to download using: pre-packaged-binary
Failed locating asset [pre-packaged-binary]: Could not find release asset for
  valkey-io/valkey-glide-php:v1.1.0 named one of
  "php_valkey_glide-v1.1.0_php8.5-x86-linux-glibc.zip,
   php_valkey_glide-v1.1.0_php8.5-x86-linux-glibc.tgz,
   php_valkey_glide-v1.1.0_php8.5-x86-linux-glibc-nts.zip,
   php_valkey_glide-v1.1.0_php8.5-x86-linux-glibc-nts.tgz"
Selected download URL method: composer-default

PIE searches for x86 assets. The release contains php_valkey_glide-v1.1.0_php8.5-x86_64-linux-glibc.zip which is not matched.

Suggested fix

Add underscore to the character class:

preg_match('/Architecture([ =>\t]*)(x[0-9_]*)/', $phpinfo, $m)

Impact

This affects every 64-bit Linux system. The pre-packaged-binary download method will never match x86_64 assets — it always looks for x86. Extensions that ship pre-built binaries with the PIE-documented x86_64 architecture name will fall back to source compilation on every install.

Note: ptondereau/biscuit-php also uses x86_64 in their release asset names, so this bug likely affects them too.

Version

PIE 1.4.x branch (commit from 2026-03-15). The feature is not yet in a released version.

[asgrim]

The assessment & suggestion is entirely wrong I'm afraid; the regex you're looking at is for Windows only (which will detect x32 or x64). The architecture for x86_64 is already detected above that block.

However; I've looked at https://github.com/valkey-io/valkey-glide-php/releases and there are no releases. There also is not a stable 1.1.0 release to check this with, let alone any releases supporting the upcoming pre-packaged binary feature.

If you are able to provide more information on how you are reproducing this, I may be able to help, and also please provide the full pie show -v output.

[derrickschoen]

Thanks for the correction — you're right that the regex is intended for Windows. The issue is that Amazon Linux 2023's PHP includes Architecture => x86_64 in phpinfo() output, which Debian/Ubuntu PHP does not. The regex matches on AL2023, captures x86 (underscore stops [0-9]*), and overrides the correct x86_64 from the PHP_INT_SIZE check above it.

pie show -v output

Target PHP installation: 8.5.3 nts, on Linux/OSX/etc x86 (from /usr/bin/php)

Reproduction on a fresh AL2023 x86_64 EC2 instance

=== PIE Architecture Detection Bug — Reproduction ===
Host: x86_64
OS: "Amazon Linux 2023.10.20260302"

--- phpinfo Architecture line (only exists on AL2023, not Debian/Ubuntu) ---
Architecture => x86_64

--- BEFORE FIX: pie show -v ---
Target PHP installation: 8.5.3 nts, on Linux/OSX/etc x86 (from /usr/bin/php)

--- Applying fix: guard regex with Windows check ---
Patched.

--- AFTER FIX: pie show -v ---
Target PHP installation: 8.5.3 nts, on Linux/OSX/etc x86_64 (from /usr/bin/php)

=== Done ===

Reproduction script

Run on an Amazon Linux 2023 x86_64 instance:

#!/usr/bin/env bash
set -euo pipefail

echo "=== PIE Architecture Detection Bug — Reproduction ==="
echo "Host: $(uname -m)"
echo "OS: $(cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2)"
echo ""

rm -rf /tmp/pie

if ! command -v php &>/dev/null; then
    echo "--- Installing PHP ---"
    sudo dnf install -y php-cli php-devel php-xml php-mbstring git unzip 2>&1 | tail -3
    echo ""
fi

echo "--- phpinfo Architecture line (only exists on AL2023, not Debian/Ubuntu) ---"
php -i | grep "^Architecture" || echo "(not found)"
echo ""

echo "--- Installing PIE 1.4.x ---"
git clone --branch 1.4.x --depth 1 https://github.com/php/pie.git /tmp/pie 2>&1 | tail -1
cd /tmp/pie
curl -sS https://getcomposer.org/installer | php 2>&1 | tail -1
php composer.phar install --no-dev --quiet
echo ""

echo "--- BEFORE FIX: pie show -v ---"
/tmp/pie/bin/pie show -v 2>&1 | grep "Target PHP"
echo ""

echo "--- Applying fix: guard regex with Windows check ---"
sed -i '/preg_match.*Architecture/{i\            $osFamily === OperatingSystemFamily::Windows &&
}' /tmp/pie/src/Platform/TargetPlatform.php
echo "Patched."
echo ""

echo "--- AFTER FIX: pie show -v ---"
/tmp/pie/bin/pie show -v 2>&1 | grep "Target PHP"
echo ""

echo "=== Done ==="

Proposed fix

Guard the regex with a Windows check since it's only needed there. $osFamily is already resolved at that point:

if (
    $osFamily === OperatingSystemFamily::Windows
    && preg_match('/Architecture([ =>\t]*)(x[0-9]*)/', $phpinfo, $m)
    && array_key_exists(2, $m)
    && $m[2] !== ''
) {
    $architecture = Architecture::parseArchitecture($m[2]);
}

[asgrim]

I will investigate and fix this issue, but please in future be more respectful to my time (and other open source maintainers, I am sure) by not just copy/pasting with LLM generated content.

[derrickschoen]

I will investigate and fix this issue, but please in future be more respectful to my time (and other open source maintainers, I am sure) by not just copy/pasting with LLM generated content.

Hi,
Derrick here. Sorry for the trouble.
Aws support told my boss to use glide instead of phpredis.
The build times are a problem.

I forked valkey-io/valkey-glide-php to have pre-built binaries ready for when Pie 1.4 comes out.

I tested it out with the Pie 1.4 branch on an instance with AL2023, and discovered that it wasn't working.
Claude Code found that the platform name was being shortened to x86 from the required x86_64 because of the regex block highlighted in the initial ticket. Adding the underscore did fix the issue and let me test the built binaries.

I see now, that I should have double checked the bug on Ubuntu as well before raising the issue.

What else should I have done better? I really do want to be good to the maintainers of the tools that I use.

P.S.
What would be the best way to raise the issue when a maintainer may be mistaken?
I know it is a touchy subject and I don't want to be a jerk, but, I did confirm that the block that you said was for Windows only was causing problems with Amazon Linux.
Sorry to take up more of your time, but I want to learn how to be a better community member.

Thanks,
Derrick Schoen

[asgrim]

@derrickschoen I very much appreciate you circling back with more context, and written by a human is far higher quality information; thank you! ❤️

Primarily, the best reports contain info like:

• what are you trying to do?
• how are you trying to do it (i.e. steps to reproduce)?
• what do you expect to see?
• what do you actually see?

This set of information is always a great starting point to help maintainers work out what is going on - some OSS projects will ask for more, or maybe different things if necessary, but hopefully they'll put that in the issue template, for example. The key I think here is there's something going on with Amazon Linux, which I will try out to see if I can confirm what's going on. If I can't reproduce the issue, I may come back to you asking for more information to help me reproduce the issue.

The thing that took time, and was frustrating from my perspective, is that the LLM responses were incredibly verbose, and difficult to read, purely because of how LLMs generate content; it was about 80% waffle, and 20% actually useful information. But, as a maintainer, I have to read through all the information to distil it down to the actual useful points. FWIW, you have demonstrated by replying to me personally that you're certainly not a jerk, and I think it's really awesome and commendable that you engaged to find out how to improve. Likewise, if there is anything I can do to be better in things like this, I'm happy to learn too :) have an awesome day!