Topic: PHP 8.5.7 and curl 8.20.0 require loading of brotli and zstd

[danielruf]

It seems newer PHP versions (also includes PHP 8.4.x) ship with curl 8.20.0, which requires to load brotli(dec.dll) and (lib)zstd(.dll).

Otherwise Apache fails to start, when one of the newer PHP releases with curl 8.20.0 or newer is used.

Is this on the radar of the ApacheLounge team? Will there be some changes in the ApacheLounge Apache builds or is this just something that has to be documented, so PHP users are aware of it and related bugreports can be pointed to the documentation?

https://github.com/php/php-src/issues/22157
https://github.com/php/php-src/pull/21925

[admin]

It is on our radar.

We build the Lib and the DLL in the next APACHE.

[Steffen]

New version available.

In the changelog :

*) Added ZSTD libraries (zstd.dll, zstdt.exe, zstd.lib, zstd_ststic.lib) to help with third party support.


*) Added ZSTD support in Curl.

[danielruf]

Hm, I still have to add the following to apache/conf/httpd.conf to have curl loaded according to phpinfo():

LoadFile "${basePath}/php/brotlidec.dll"
LoadFile "${basePath}/php/libzstd.dll"

So did I mix something up and this has to be manually done even with your latest changes? What is the preferred solution for users running PHP 8.5.7 on Apache 2.4.68 from 17th of June 2026?

[danielruf]

not relevant probablx, but there were some changes affecting zlib dll names: https://github.com/php/php-src/issues/22157#issuecomment-4734454260

[tangent]

[danielruf]

following tried:

LoadFile "bin/brotlidec.dll"
LoadFile "bin/zstd.dll"

Results in:

[18-Jun-2026 06:41:40 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'curl' (tried: C:\...\php\ext\curl (Das angegebene Modul wurde nicht gefunden), C:\...\php\ext\php_curl.dll (Das angegebene Modul wurde nicht gefunden)) in Unknown on line 0


Tried:

LoadFile "/bin/brotlidec.dll"
LoadFile "/bin/zstd.dll"

Leads to the Apache Service not starting on Windows (Fails with an error:

Der Dienst "apache2.4" wurde mit dem folgenden dienstspezifischen Fehler beendet:
Unzulässige Funktion.


Tried:

LoadFile "${basePath}/apache/bin/brotlidec.dll"
LoadFile "${basePath}/apache/bin/zstd.dll"

Results in:

[18-Jun-2026 06:45:28 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'curl' (tried: C:\...\php\ext\curl (Das angegebene Modul wurde nicht gefunden), C:\...\php\ext\php_curl.dll (Das angegebene Modul wurde nicht gefunden)) in Unknown on line 0

Only the following works for me and adds the curl section in the Output of phpinfo():

LoadFile "${basePath}/php/brotlidec.dll"
LoadFile "${basePath}/php/libzstd.dll"

[admin]

Just try only the zstd.dll and libzstd.dll.

brotli we have it already for years.

We build from zstd-1.5.7.tar.gz from the bottom of page https://github.com/facebook/zstd/releases.

And have no libzstd.dll

[danielruf]

[admin]

Just try only to include zstd, to see if the issue is brotli or zstd

I think it is a PHP issue. The way it is build causes add some LoadFile.

[danielruf]

Understood, thank you.

I've now added only the following, instead of brotlidec + libzstd:

LoadFile "${basePath}/php/libzstd.dll"

This seems to work (we generally load the versions shipped with the PHP builds for Windows).

I'll try to report the requirement for this LoadFile in the PHP project. Maybe ther eis something that can be fixed / improved. At least to me it makes not much sense to manually add this, when the libraries are there in Apache and PHP is running as Apache module.

Edit: opened an issue at https://github.com/php/php-src/issues/22359 - maybe some mismatch leads to this

[tangent]

[Steffen]

First try copy zstd.dll to libzstd.dll to see if that works.

I want first the reason why PHP builds libzstd.dll ?

[danielruf]

Frankly I can not answer, why PHP builds libzstd.dll. As far as I understood, they statically build and include the library via cmake or something like that.

Good news is, that it should not happen with the next PHP release, see https://github.com/php/php-src/issues/22359#issuecomment-4745323072

* copied the file as mentioned in apache/bin (zstd.dll => libzstd.dll).
* removed LoadFile "${basePath}/php/libzstd.dll" from my httpd.conf.
* restarted the Apache service
* reloaded page with phpinfo output
* curl is successfully loaded now

So it seems it is connected to the lib* => * renaming. Something similar happenend with zlib. Why that is so? I don't know.

To me as someone from the outside it looks like this:
* curl changed their requirements (breaking change imho, made in a minor update)
* the whole ecosystem has to adapt (PHP, Apache and likely other distros, packages, ...)

Not sure if and how well this was communicated in the ecosystem.

[tangent]

Thanks to you and @Jan-E for following this through with the PHP developers so quickly, and yes, it looks like their solution going forward will be to link with ZSTD statically. So there will be no need to change the ZSTD names in the Apache Lounge build.

What's interesting in looking through the PHP post is reference to winlib-builder patch https://github.com/winlibs/winlib-builder/blob/master/patches/libzstd.patch, where a decision was made to change the ZSTD library names from zstd to libzstd. This is what has caused this issue, in a similar way to the problems ZLIB caused by changing the names of their libraries in their most recent update.

The downside of linking things statically is program sizes and memory requirements go up; like most things in life it's a compromise.

Regarding the 'ecosystem' needing to adapt, we are looking at the Open Source movement. There are some really clever guys out there, who as developers choose to give their own time and expertise in co-operative ventures to the best of their abilities. I take my hat off to them.