I haven't tested if this works on macOS, but it doesn't conflict with sodium on linux.

Hmm, this will fall over with ld.lld when -lsodium is linked before -largon2. We'll have to make sure to order them correctly in spc.

Made sure of it in SPC. PHP can now want them in the "wrong" order and SPC will patch it to be correct.

Thanks!

You know that password supports Argon2 through OpenSSL since 8.4?

not for ZTS builds, unfortunately

https://github.com/php/php-src/blob/PHP-8.4.11/ext/openssl/config0.m4#L53

Once that's changed, I'll remove libargon2 (if it can even be called that).

Ah yeah, I should make it supported in 8.5 as I have libctx there for some parts. Will do it as the next thing in my libctx quest... :)

I wish we could get NTS versions dropped in 9.0, if you're looking for things to do :P
Probably not realistic because of the 2-3% performance difference, but availability of FrankenPHP would be in a massively better state if the default option everywhere wasn't NTS.

php/php-src#19236 just got merged so it should work in 8.5

Yep I followed the thread, thank you.

Maybe a bit concerning right now is that our compiled binaries are ~25% slower than Remi's, according to phoronix phpbench. The ZTS/NTS split isn't it (~1%ish), the compiler or different compilation options aren't it either. Might have to open issues in a few different places when I eventually get to the bottom of it.

You mean for password hash and argon2?

No, unrelated. Basically the frankenphp builds, my php-zts repo and also the docker (bookworm) images score much lower in phpbench than remi's distribution.

Gcc --disable-gcc-global-regs: 110k ZTS
Clang build: 113k ZTS & NTS, 115k with LTO
Docker (bookworm) images: 120k NTS
Gcc from source: 136k ZTS, 137k NTS
Mostly static gcc: 137k ZTS
Remi: 156k NTS
Recompile remi's with rpmbuild (Gcc): 160k ZTS, 161k NTS

Each of these has <0.5% variance across multiple tests over the course of 2 days. Still haven't figured it out.