I want to use zlib-ng with nginx because its performance is better than zlib.
Phoronix wrote about zlib-ng 2.3.1 here:
For nginx, there is an official patch set from zlib-ng here:
But I cannot clearly understand how these patches are supposed to be used with nginx.
The documentation is very small, and I could not find a step-by-step example.
If someone knows the intended way to use these patches with nginx, please let me know.
In the nginx CHANGES file and mailing list, I can see several entries about zlib-ng, for example:
“Gzip: support for zlib-ng.”
“Gzip: compatibility with recent zlib-ng versions.”
A workaround: "gzip filter failed to use preallocated memory" alerts appeared in logs when using zlib-ng.
So clearly nginx developers do test and care about zlib-ng support. However, I do not understand what official usage they expect:
Which zlib-ng mode (native API vs --zlib-compat)?
Static link or dynamic link?
Any special build flags?
I could not find documentation that explains this clearly.
Below I will explain what I am doing now. I would like to know if this matches the intended usage or if there is a better way.
My understanding of nginx + zlib-ng
zlib-ng by default exposes its own API.
With --zlib-compat it can provide a zlib-compatible API.
I guess the official zlib-ng patches for nginx are for the native zlib-ng API.
For now I only want to use zlib-ng in zlib-compat mode and link it statically into nginx, so that it behaves like a zlib drop-in replacement.
Problem: passing options to zlib-ng ./configure from nginx
To enable zlib-compat mode, we must pass options to zlib-ng’s ./configure script.
But nginx’s build system does not have an option to pass extra flags to zlib’s ./configure when using:
--with-zlib=/path/to/zlib-or-zlib-ng
Because of this, I created a small patch for nginx:
This PR adds a new configure option:
--with-zlib-conf-opt=...
These options are passed directly to the ./configure call in the zlib (or zlib-ng) source directory.
With this patch, I can build nginx like this (simplified example):
By default, nginx is designed to work with the zlib-compatible api of zlib-ng, rather than the new native API. Without patches it will only work with zlib-ng if the library is built in compat mode. So, the recommended approach is to compile zlib-ng in zlib-compatibility mode and link it as if it were regular zlib.
I haven’t tried building nginx with these patches, but it looks like you can try adapting them, say for 1.29.3, and check whether they work.
I don’t think it makes a big difference how you plan to link zlib-ng. If you are doing it statically, then without support for --with-zlib-conf-opt you can still do it by modifying configure in the zlib-ng directory and changing compat=0 to compat=1. Dynamic linking (using a system-wide zlib-ng) should also work, just make sure that the system’s zlib.h and libz.so come from the zlib-ng compat.
Thank you very much for your detailed explanation.
The setting you describe is basically the --zlib-compat option of zlib-ng.
If I build zlib-ng with --zlib-compat, nginx works fine for me, even with the latest versions (for example nginx 1.29.3 with zlib-ng 2.3.1).
Because nginx’s build system cannot pass extra options to zlib’s ./configure when using --with-zlib=..., I have already created a small patch that adds a new option:
--with-zlib-conf-opt=...
These options are passed directly to the ./configure script in the zlib (or zlib-ng) source directory. With this patch I can build nginx like this:
This way nginx is statically linked with zlib-ng built in compat mode, and it works correctly in my tests.
So my main point is that the “setting” to change is the --zlib-compat option of zlib-ng, and if we can pass this option at nginx compile time, nginx already works well with recent zlib-ng releases. My patch only tries to make it possible to pass this option from the nginx build, instead of editing the zlib-ng configure script by hand.
If you have any comments on this approach, or if there is a better nginx-style way to handle this, I would be very happy to adjust the patch.
If you’re asking purely about whether it makes sense to add an additional option to the build params, it’s best to discuss that in your PR. Personally, I don’t think this option is strictly necessary, because you can build zlib-ng with the --zlib-compat flag and then specify the include and lib paths with the --with-cc-opt and --with-ld-opt flags, like:
I understand that your example with --with-cc-opt and --with-ld-opt works when using a system-wide zlib-ng (usually as a shared library under /opt/zlib-ng etc.). However, my main goal is a build where nginx statically links zlib-ng using the existing --with-zlib=/path/to/zlib-ng flow.
In this flow nginx runs ./configure inside the zlib/zlib-ng source tree by itself, and there is currently no way to pass extra options like --zlib-compat to that ./configure script. That is exactly why I added the --with-zlib-conf-opt=... option in my patch: it only extends the existing --with-zlib=... mechanism and lets me keep all third-party libraries statically linked into one nginx binary.
Using --with-cc-opt / --with-ld-opt to point to /opt/zlib-ng is a different deployment style (system-wide install, usually dynamic linking), and I was trying to avoid that in my use case.
So my question in the PR is specifically about supporting the “in-tree, statically linked zlib-ng via --with-zlib” scenario. If you think this use case is not something nginx wants to support, or if there is already an nginx-style way to keep static linking and still pass --zlib-compat, I would be happy to adjust the patch accordingly.
Not exactly. You can check out zlib-ng into any dir you prefer (I usually use /opt), build it with the required options, and then tell nginx where to find the necessary libs:
git clone --branch 2.3.2 git@github.com:zlib-ng/zlib-ng.git
cd zlib-ng && ./configure --zlib-compat
make -C clean
make -j8 -C
...
auto/configure --with-cc-opt=-I/path/zlib-ng/include --with-ld-opt=-L/path/zlib-ng/lib
I think there may be a misunderstanding about my point.
I already know that dynamic linking is possible.
My concern is specifically that there is no clear way to use zlib-ng with static linking through nginx’s normal build flow.
With --with-zlib=/path, nginx builds the library from source, but it cannot pass required options to zlib-ng’s ./configure (e.g. --zlib-compat).
So a compat-mode static build is not achievable via the official flow today.
Building zlib-ng first and then building nginx can be a workaround, but it bypasses the --with-zlib mechanism.
It feels unnatural for nginx to recommend that as the primary approach.
That’s why I proposed --with-zlib-conf-opt as a small, generic improvement to make the normal static build path work.
I reread your initial message, and it seemed to me that the question was about possible ways to address this issue in a broader sense. As you can see, we tried to respond to those points. As for your specific question, I fully understood it, but as I mentioned earlier, the appropriateness of your PR is best discussed within the PR itself. Thank you for your understanding.
I think the main issue is not whether zlib-ng works, but how nginx expects us to build it, especially how to pass zlib-ng configure options with --with-zlib=....
To keep this thread short, I opened a PR that adds a small option:
--with-zlib-conf-opt="..."
If you have any opinions on the expected zlib-ng mode (native vs compat) or the right build-system approach, please share them on the PR.