Add PHP 8.5 initial support

[crazywhalecc]

What does this PR do?

Support PHP 8.5 alpha.

• Fix Switch argon2 implementation to openssl in 8.5 #839

TODO

• Check and fix upstream phpmicro patches (fixed in Update static_extensions_win32 and win32 patches for PHP 8.5 alpha1 dixyes/phpmicro#5 )
  • cli_checks
  • comctl32
  • disable_huge_page
  • macos_iconv
  • phar
  • static_extensions_win32
  • static_opcache (PHP 8.5 doesn't need to patch opcache)
  • vcruntime140
  • win32
  • zend_stream
• Update static-php.dev docs
• Update README.md
• Waiting upstream response PHP 8.5 windows support easysoft/phpmicro#23 https://github.com/static-php/phpmicro/pull/8/files

Tracked all unsupported things and future versions in #842 .

Checklist before merging

If your PR involves the changes mentioned below and completed the action, please tick the corresponding option.
If a modification is not involved, please skip it directly.

• If you modified *.php or *.json, run them locally to ensure your changes are valid:
  • PHP_CS_FIXER_IGNORE_ENV=1 composer cs-fix
  • composer analyse
  • composer test
  • bin/spc dev:sort-config
• If it's an extension or dependency update, please ensure the following:
  • Add your test combination to src/globals/test-extensions.php.
  • If adding new or fixing bugs, add commit message containing extension test or test extensions to trigger full test suite.

[henderkes]

Hahaha, I have been working on this, too.

[henderkes]

We should also put a watch on php/php-src#18660 because it might land in 8.5.

[henderkes]

It was merged, opcache is always statically compiled into php 8.5.

[crazywhalecc]

Looks like we have to wait alpha3 or test master branch directly.

[crazywhalecc]

We should also put a watch on php/php-src#18660 because it might land in 8.5.

Looks like we don't need to patch opcache for PHP 8.5 at all. We only need to add version check and just ignore opcache extension like json, but the phpmicro project would have to create an empty patch file to avoid backward conflicts.

[crazywhalecc]

Change

[henderkes]

I find a few related issues like here: https://stackoverflow.com/questions/14078182/openssl-file-get-contents-failed-to-enable-crypto

Question is why that only happens when MUSL is defined

[crazywhalecc]

Interesting. When I use configure.ac patches instead of passing CPPFLAGS=-D__MUSL__, everything works as expected.

So the conclusion for now:

• configure.ac musl check not working with cross toolchain.
• CPPFLAGS=-D__MUSL__ or defining anything else will make stream client with ssl verification failing or build failure: https://github.com/crazywhalecc/static-php-cli/actions/runs/16696190022/job/47260655518

Currently we could know that the ssl bug is not related to __MUSL__, but related to CPPFLAGS define.

[henderkes]

I will upstream a fix for that to php-src. There are better ways to detect musl without breaking cross-compilation.

[crazywhalecc]

I will upstream a fix for that to php-src. There are better ways to detect musl without breaking cross-compilation.

That's great! btw how do you plan to detect musl from cross toolchain?

And please review all the changes again. I will merge this branch soon and then introduce some logger refactoring based on it.

[henderkes]

Musl doesn't define the _USE_GNU macro in features.h, so we can write a feature test

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#include <sys/features.h>
#ifdef _USE_GNU
#error Not using musl
#endif

and try to compile that. Won't break cross-compilation.

[henderkes]

php/php-src#19352

[henderkes]

this is not needed, I mean that we must disable the fake password-argon2 extension in case openssl-argon2 is used.

[crazywhalecc]

Ah got it. But --with-password-argon2 is different from --with-openssl-argon2. Considering that Herd and some laravel projects use it, and it has not been deprecated yet, we should treat them separately. We cannot remove it until password-argon2 is deprecated in PHP standard extension.

[henderkes]

with-openssl-argon2 implements the functionality of with-password-argon2. When both are defined, I'm not sure which backend will be used.

Essentially we need to have this check in both extensions and use the openssl one if possible, but fall back to the coding contest implementation.

[crazywhalecc]

According to config.m4 and function source, --with-password-argon2 is defined to use the standalone libargon2, while --with-openssl-argon2 is using openssl. And these are used from different function: password_hash and openssl_password_hash. They shouldn't conflict.

[henderkes]

password_hash exists either way. When no implementation is chosen, it falls back to libsodium (no threads option). Argon2 and openssl can change the bachend implementation, but I'm not sure which backend will be chosen in case both are enabled. Remi explicitly enables --with-openssl-argon2 and --without-password-argon2.

We want it to use the openssl backend because it's the most well-maintained implementation.

[crazywhalecc]

Looks like if we enabled libargon2, it will use it first. Otherwise it will search from zend bucket.

Anyway, I don't think we have to adjust pwhash function and dependency here. But if we could confirm and validate that openssl is able to cover it, we could make password-argon2 to depends on openssl instead of libargon2 later.

[henderkes]

Well, only from php 8.4 for NTS and 8.5 for ZTS sadly. My point is that we should let openssl be the backend for the password_hash function if possible. I'll look into it tomorrow.

[henderkes]

https://github.com/search?q=repo%3Aphp%2Fphp-src%20php_password_algo_register&type=code

[henderkes]

php/php-src#19360

Could simplify it a little.

[henderkes]

closes #845