Historically, PHP has supported both 32-bit and 64-bit environments. However, the vast majority of production deployments now use 64-bit systems. Major operating systems and distributions have either already dropped support for 32-bit architectures or are in the process of doing so. Maintaining 32-bit compatibility incurs development, testing, and ongoing maintenance overhead.
32-bit environments have known limitations especially because PHP's int
type being a platform-dependent signed integer. This restricts values to a range between -2,147,483,648
and 2,147,483,647
. This constraint leads to several problems:
In PHP, UNIX timestamps are the number of seconds since 1970-01-01 UTC stored in a signed integer, which results in a valid range of 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC.
Knowing the correct current time is essential in many programming patterns including ...
exp
field)The following extensions / API functions are effected ...
memcache
/ memcached
expiration time handling https://www.php.net/manual/en/memcached.expiration.phpThe only exceptions are:
int64_t
. However, using this as a workaround is risky and error-prone, especially since timestamp-related methods (e.g., DateTimeInterface::[get|set]Timestamp()
) are using PHP's signed integer type.On 32-bit builds, PHP can handle files up-to 2g only. This includes file streams as well.
On 32-bit builds, the PHP process is limited to 2g memory.
Most major platforms and Linux distributions have already ended support for 32-bit installations, though some still allow building and running 32-bit applications on 64-bit kernels.
Distribution | 32-bit Support Status |
--------------------------- | ------------------------------------------------------------------------------------ |
Ubuntu | Dropped official 32-bit kernel and install media as of 19.10 |
Debian | Dropped official 32-bit kernel and install media as of Debian 12 (Trixie) |
Fedora | Dropped official 32-bit kernel and install media as of Fedora 31 |
Arch Linux | Dropped i686 support in 2017 |
openSUSE | Dropped 32-bit builds in Leap and Tumbleweed (Leap 15+ only supports 64-bit) |
RHEL/CentOS/AlmaLinux/Rocky | RHEL 7 was the last version to support 32-bit; all current releases are 64-bit only |
Windows | Dropped support for 32-bit systems as of Windows 11 |
macOS | Dropped all 32-bit app support as of Catalina (10.15) |
Apple Silicon | 64-bit ARM only — cannot run 32-bit code at all |
Deprecate 32-bit support in the next minor release (PHP 8.x). Completely drop 32-bit support in the next major release (PHP 9.0).
Starting with PHP 9.0, it will no longer be possible to build or run PHP on 32-bit environments.
Beginning with PHP 9.0, PHP will no longer support 32-bit builds. Attempting to compile or run PHP in such environments will fail.
This RFC makes it impossible to build or run PHP on 32-bit-only platforms starting with PHP 9.0.
Also, it will not be possible to build PHP with 32-bit on 64-bit kernels.
Is it enough to inform users about this deprecation in the documentation or should the next minor release explicitly emit deprecation warnings when running or building on 32-bit builds?
64-bit builds will remain fully supported and unaffected by this change.
This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
This requires a 2/3 majority. It is straight Yes/No vote to accepting the RFC.
PR to deprecate 32bit builds of PHP : https://github.com/php/php-src/pull/18876
After the project is implemented, this section should contain
ML Year 2028 issue : https://discourse.thephp.foundation/t/php-dev-year-2038-issue/1904
ML Discussion : https://discourse.thephp.foundation/t/php-dev-rfc-drop-support-for-32bit-builds/1919
ML Vote : TBD
Keep this updated with features that were discussed on the mail lists.