[cmake] [windows] A shared library build outputs a DLL name inconsistent with previous releases and other files in the source tree

[luau-project]

Description

On Windows, building zlib 1.3.2 through CMake as a shared library outputs a dll named z.dll (MSVC) or libz.dll (MinGW/MinGW-w64).

Even though I am aware that the CMake support on 1.3.2 went on deep changes (#1027), it seems to be an inconsistency with other files in the source tree and also regarding previous releases.

Current behavior

• Inconsistency with previous releases: On zlib 1.3.1, a standard shared library build through CMake outputs a dll named zlib1.dll (MSVC) or libzlib1.dll (MinGW/MinGW-w64).

• Inconsistency with other files in the source tree: In the current zlib 1.3.2

zlib/CMakeLists.txt

Lines 157 to 160 in da607da

	if(ZLIB_BUILD_SHARED)
	add_library(
	zlib SHARED ${ZLIB_SRCS} ${ZLIB_PUBLIC_HDRS} ${ZLIB_PRIVATE_HDRS}
	$<$<OR:$<BOOL:${WIN32}>,$<BOOL:${CYGWIN}>>:win32/zlib1.rc>)

the shared library uses the file win32/zlib1.rc to define a few file properties, including the name of the dll as zlib1.dll

zlib/win32/zlib1.rc

Lines 22 to 31 in da607da

	BEGIN
	VALUE "FileDescription", "zlib data compression library\0"
	VALUE "FileVersion", ZLIB_VERSION "\0"
	VALUE "InternalName", "zlib1.dll\0"
	VALUE "LegalCopyright", "(C) 1995-2026 Jean-loup Gailly & Mark Adler\0"
	VALUE "OriginalFilename", "zlib1.dll\0"
	VALUE "ProductName", "zlib\0"
	VALUE "ProductVersion", ZLIB_VERSION "\0"
	VALUE "Comments", "For more information visit https://www.zlib.net/\0"
	END

Note

This 1.3.2 behavior is also inconsistent with the dll name defined on Makefile-based builds for MSVC and MinGW-w64:

• zlib/win32/Makefile.msc

  Lines 15 to 18 in da607da

  	# variables
  	STATICLIB = zlib.lib
  	SHAREDLIB = zlib1.dll
  	IMPLIB = zdll.lib

• zlib/win32/Makefile.gcc

  Lines 28 to 30 in da607da

  	STATICLIB = libz.a
  	SHAREDLIB = zlib1.dll
  	IMPLIB = libz.dll.a

Expected behavior

The same on zlib 1.3.1, which outputs a dll named zlib1.dll (MSVC) or libzlib1.dll (MinGW/MinGW-w64).

Reproduction

I wrote a GitHub workflow to demonstrate this behavior comparing zlib versions (1.3.1 versus 1.3.2) on both MSVC and MinGW-w64. Log in to GitHub and inspect the runs: https://github.com/luau-project/ci-tests/actions/runs/22265467727

Click here to toggle the workflow

name: Test

on: push

jobs:
  zlib-test:
    runs-on: windows-latest

    defaults:
      run:
        shell: cmd

    strategy:
      fail-fast: false

      matrix:
        zlib-version:
          - 1.3.1
          - 1.3.2

        toolchain:
          - msvc
          - gcc

    steps:
      - name: Setup MSVC developer prompt
        uses: ilammy/msvc-dev-cmd@v1
        if: ${{ matrix.toolchain == 'msvc' }}

      - name: Download zlib
        run: curl -L -O "https://zlib.net/fossils/zlib-${{ matrix.zlib-version }}.tar.gz"

      - name: Extract zlib
        run: tar -xf "zlib-${{ matrix.zlib-version }}.tar.gz"

      - name: Configure zlib through CMake
        run: |
          IF "${{ matrix.toolchain }}" EQU "msvc" (
            SET "CMAKE_GENERATOR=NMake Makefiles"
          ) ELSE (
            SET "CMAKE_GENERATOR=MinGW Makefiles"
          )

          IF "${{ matrix.zlib-version }}" EQU "1.3.2" (
            cmake -G "%CMAKE_GENERATOR%" ^
              -DCMAKE_BUILD_TYPE=Release ^
              -DZLIB_BUILD_SHARED=ON ^
              --install-prefix "C:\zlib" ^
              -S "zlib-${{ matrix.zlib-version }}" ^
              -B "build-zlib"
          ) ELSE (
            cmake -G "%CMAKE_GENERATOR%" ^
              -DCMAKE_BUILD_TYPE=Release ^
              -DBUILD_SHARED_LIBS=ON ^
              --install-prefix "C:\zlib" ^
              -S "zlib-${{ matrix.zlib-version }}" ^
              -B "build-zlib"
          )

      - name: Build zlib
        run: cmake --build "build-zlib" --config Release

      - name: Install zlib
        run: cmake --install "build-zlib" --config Release

      - name: Show zlib installation directory
        run: tree /F "C:\zlib"

Why is this important ?

On Windows, some applications load zlib dynamically based on dll name using the WINAPI (LoadLibrary + GetProcAddress)

[Vollstrecker]

Beside this overflow of information, combined with a workflow just for this which reminds of that AI generated crap that forced curl to shutdown it's bug-bounty program.

You've seen that there is a zlib1.dll in cmake aswell?

And yes, this is inconvenient if you hardcode libnames, but for all people that do such a thing, the Makefile should be enough. All others should just use the provided configs and don't need to care about lib-names as they work with targets and beside the addition of ZLIB::ZLIBSTATIC they are still consistent with cmake 2.x from a decade ago.

[luau-project]

Beside this overflow of information, combined with a workflow just for this which reminds of that AI generated crap that forced curl to shutdown it's bug-bounty program.

No, it is not AI crap, because I wrote it by hand and I think it is important to prove my points in a reproducible way.

You've seen that there is a zlib1.dll in cmake aswell?

If you meant the CMake project on contrib/zlib1-dll, then yes, I did. However, on a patch release (1.3.X), I would expect the way to configure the build through CMake would remain the same. But it looks like I was mistaken, and on every patch release users will have to guess what's going on.

If you think this issue doesn't make sense, feel free to close it as work as designed or other appropriate reason.

[Vollstrecker]

Just checked on the action:

• Mac: libz.dylib
• MSys: libz.dll
• Ubuntu: libz.so
• Windows (GCC): with libz.dll

For whatever reason MSVC (z.dll) breaks this and cygwin does it completely wierd with producing zlib.dll.exp and cygz.dll.
So yes, for consistency they both need special threatment.

[luau-project]

Dropping another evidence why the dll name matters (see 1. and 2.: https://zlib.net/DLL_FAQ.txt).

[Vollstrecker]

Dropping another You've seen that there is a zlib1.dll?

For consistency there will be libz.* everywhere, If someone really relies on zlib1.dll, it can be built. Can you show me a realworld example that relies on cmake and on a hardcoded libname?

[luau-project]

One of the most used projects in the world (OpenSSL), can be configured to load zlib dynamically as part of their build process (https://github.com/openssl/openssl/blob/1c34275e6112b8af8a5897cb31bbc7de180ba464/INSTALL.md?plain=1#L446-L449) and expects to find a zlib1 dll at runtime (https://github.com/openssl/openssl/blob/1c34275e6112b8af8a5897cb31bbc7de180ba464/crypto/comp/c_zlib.c#L272-L295).

I think I've sent you plenty of different resources, some of them publicly available in decades, where the DLL name is expected to be zlib1. You just seem to ignore this fact, holding a point to prove against the project's own files and common sense.

I am certainly not against changes. However, breaking changes are not expected to be on a patch release.

[Vollstrecker]

Beside that this is not an example that uses cmake which is what I asked for as the Maekfiles are not changed, and there is no reason to compile a new zlib with cmake while still having to do all the other stuff the old way.

They already take care of such things as they have --with-zlib-lib option, so even when cmake is used, when configuring on Win without any options the hardcoded name is not relevant and if you give an option so this becomes relevant, it's not really hard to give a second option and nothing breaks.

The libnames a re now (as in around 3 hours) consistent across all plattforms, so your mentioned lines 272 - 295 can shrink to just one line, that's a real benefit for everyone, but it's nothing that justifies a new major version.

And again, noone that's using cmake for their stuff will notice any difference and I honestly see no reason to use cmake for my own stuff but not using it for the deps or vice versa.

[jcar87]

When one links against an import library on Windows (typically the .lib extension), the name of the expected DLL is hardcoded in the linked artifact (the resulting .exe or .dll). This isn't something "unusual" or voluntary that only eccentric developers do, this is how all platforms work where executables and shared libraries have the names of their shared library dependencies hardcoded in by the linker - libz.so.1 or libz.1.dylib or similar. The name of the shared library is part of the interface.

The problem is not just limited to programs that use dlopen and load the DLL at runtime based on a previously known name, but literally any previously linked program will still expect zlib1.dll or whichever filename it was using before.

This will cause issues in any scenario where one is not rebuilding all the downstream users of zlib. So, for starters, it might affect all package repositories that support Windows and have pre-existing binaries (e.g. Conda, Conan, vcpkg, msys2).

• I can see that Conda is already having issues with the new version due to some files having changed (logs here). The Conda recipe already uses/expects multiple DLL names on Windows, (see here and here), precisely to support executables or libraries that were built expecting those DLLs - none of those names are z.dll.
• in Conan we cannot move forward with 1.3.2 as it is because it produces a different dll name - all pre-built binaries of anything that used zlib would stop working.
• I can only imagine that with vcpkg it will be similar since binaries can be cached too

Relying on stable DLL names (and stable ABI) is critical to avoid the resource demand of having to rebuild everything from source. That's why this is typically considered a breaking change, typically reserved for ABI breaks, that tend to merit a "major" version bump, to signal to distros that downstream consumers need to be rebuilt too.

And again, noone that's using cmake for their stuff will notice any difference and I honestly see no reason to use cmake for my own stuff but not using it for the deps or vice versa.

This is quite strange reasoning. On Windows, the filename of the .DLL is NOT needed by consumers to produce a binary, irrespective of the build system, CMake or not, as the linker only needs to know the name of the import library (typically the .lib extension). With CMake, the latter is abstracted away by the imported targets, but still: it doesnt need to know where the DLL is, or even what the name is - so of course nothing is "broken" in that context, making this an absurd ask.

The libnames a re now (as in around 3 hours) consistent across all plattforms, so your mentioned lines 272 - 295 can shrink to just one line, that's a real benefit for everyone, but it's nothing that justifies a new major version.

But it sounds to me that they are not consistent if the makefiles are still producing different filenames on Windows? On platforms where the average developer might expect the scripts to be interchangeable (e.g msys2), they'll find that they're not.

As it stands:

• Package repositories that support Windows and use CMake to build zlib, will have to take further steps to ensure that zlib1.dll is packaged in, pretty much indefinitely.
• Users that rely on pre-built binaries of things that use zlib (e.g Python, Qt, some of the CUDA libraries), may have to be careful mixing their binaries and these prebuilt ones, because the name of the zlib DLL may be different depending on whether CMake was used to build it, and depending on whether or not they built version 1.3.2 or a prior one
• Users that create relocatable bundles on Windows and use a shared variant of ZLIB, may have to tweak their scripts to support the new DLL name (or package zlib1.dll too)
• Libraries that load zlib dll via dlopen (like OpenSSL!!) - will have to change too. OpenSSL offers a compile-time toggle for the expected DLL name, but does not seem to support it trying multiple names until it finds one that works. Again, bundling zlib1.dll would solve this too.

You've seen that there is a zlib1.dll in cmake aswell?
Dropping another You've seen that there is a zlib1.dll?

I've gone over this thread a couple of times, then went to see the code, and this was not particularly evident. Now, the code I can understand, the rude comment not so much. Please allow me to try re-word your message in a way that I hope is what you actually meant:

We have left an alternative CMakeLists that generates zlib1.dll instead, please see contrib/zlib1-dll/CMakeLists.txt. Alternatively, you may wish to enable the ZLIB_BUILD_ZLIB1_DLL option in the root CMake so that the zlib1.dll is also produced on Windows.

I think it goes without saying that zlib is one of the most used libraries. A change like this can be very disruptive, especially as the release notes make absolutely no mention of this at all, and zlib itself has a very good tradition of not breaking anything across releases, and this makes a departure from the tradition.

Thanks @luau-project as I can see you've taking quite some time to report this and reason this - I wish most of the issue reports in the repositories I manage where as nicely detailed.

[Vollstrecker]

When one links against an import library on Windows (typically the .lib extension), the name of the expected DLL is hardcoded in the linked artifact (the resulting .exe or .dll). This isn't something "unusual" or voluntary that only eccentric developers do, this is how all platforms work where executables and shared libraries have the names of their shared library dependencies hardcoded in by the linker - libz.so.1 or libz.1.dylib or similar. The name of the shared library is part of the interface.

Beside Windows, nothing changed. And windows typically link statically or bundles the libs with their binary in the installer. I don't know over any prog on win that relies on systemwide zlib being present. And if there are any, why should a user update that on by itself, without updating that prog?

The problem is not just limited to programs that use dlopen and load the DLL at runtime based on a previously known name, but literally any previously linked program will still expect zlib1.dll or whichever filename it was using before.

And how many of these programs are not recompileable? Yes, on a point-release you don't expect such a thing, but you usually don#t update libs for progs you can't update.

This will cause issues in any scenario where one is not rebuilding all the downstream users of zlib. So, for starters, it might affect all package repositories that support Windows and have pre-existing binaries (e.g. Conda, Conan, vcpkg, msys2).

That's right, vcpkg is compiling from source, so the changes will be included. I don't know the others, but if they are spreading binaries, they should have an option for rebuilding the stuff that uses it.

* I can see that Conda is already having issues with the new version due to some files having changed (logs [here](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=1464630&view=logs&j=fe7faf59-69bb-5487-b8fd-a35a7bda3a51&t=55731638-dd49-5144-2129-5101b9dd1960&l=2806)).

This fails because of a hardcoded name in a copy statement. Seems like automated script that just changes the location to pull from. Nothing unfixable.

* The Conda recipe already uses/expects _multiple_ DLL names on Windows, (see [here](https://github.com/conda-forge/zlib-feedstock/blob/3240862e6d0edaa8ec1e624301628c8056950ba0/recipe/bld.bat#L73-L75) and [here](https://github.com/conda-forge/zlib-feedstock/blob/3240862e6d0edaa8ec1e624301628c8056950ba0/recipe/bld.bat#L37-L42)), precisely to support executables or libraries that were built expecting those DLLs - none of those names are `z.dll`.

I see that this recipe has hardcoded names. As pkg-config and cmake report the right locations I see no reason of hardcoding these names somewhere else than in this recipe where it can be adjusted easily.

* in Conan we cannot move forward with 1.3.2 as it is because it produces a different dll name - all pre-built binaries of anything that used zlib would stop working.

Sure, and it's a one-time rebuild.

* I can only imagine that with vcpkg it will be similar since binaries can be cached too

Beside vcpkg insists on building either shared OR static (but by default debug AND release), they will have maybe other problems to solve. And caching binaries without the possibility to trigger a rebuild if needed is just bad design.

Relying on stable DLL names (and stable ABI) is critical to avoid the resource demand of having to rebuild everything from source. That's why this is typically considered a breaking change, typically reserved for ABI breaks, that tend to merit a "major" version bump, to signal to distros that downstream consumers need to be rebuilt too.

In times of AI the resource-demand of rebuilding the consumers one-time is shouldn't be in mentionable regions.

And again, noone that's using cmake for their stuff will notice any difference and I honestly see no reason to use cmake for my own stuff but not using it for the deps or vice versa.

This is quite strange reasoning. On Windows, the filename of the .DLL is NOT needed by consumers to produce a binary, irrespective of the build system, CMake or not, as the linker only needs to know the name of the import library (typically the .lib extension). With CMake, the latter is abstracted away by the imported targets, but still: it doesnt need to know where the DLL is, or even what the name is - so of course nothing is "broken" in that context, making this an absurd ask.

I get that paragraph as everything OK.

The libnames a re now (as in around 3 hours) consistent across all plattforms, so your mentioned lines 272 - 295 can shrink to just one line, that's a real benefit for everyone, but it's nothing that justifies a new major version.

But it sounds to me that they are not consistent if the makefiles are still producing different filenames on Windows? On platforms where the average developer might expect the scripts to be interchangeable (e.g msys2), they'll find that they're not.

Right, as I just assume if you use cmake, then you use it for everything possible (and I'm aware that some projects downstream need some help to pick this up) and if you don't use cmake, then you also don't use it for your deps where avoidable. I'm aware cmake-based users will have a little work and I'm willing to help them, but I can't do this for pure Makefiles, autoconf etc. That's why I didn't change anything there.

As it stands:

* Package repositories that support Windows and use CMake to build zlib, will have to take further steps to ensure that zlib1.dll is packaged in, pretty much indefinitely.

Nope, when downstream packages has adopted this, it's not needed at all. Not instant, but work in progress, I myself am rebuilding everything that's depending on zlib directly from Debians archive to identify them.

* Users that rely on pre-built binaries of things that use zlib (e.g Python, Qt, some of the CUDA libraries), may have to be careful mixing their binaries and these prebuilt ones, because the name of the zlib DLL may be different depending on whether CMake was used to build it, and depending on whether or not they built version 1.3.2 or a prior one

And again, updating just a little part for whatever reason should always include a check if something else need a rebuild.

* Users that create relocatable bundles on Windows and use a shared variant of ZLIB, may have to tweak their scripts to support the new DLL name  (or package zlib1.dll too)

And again, this will need to be changed and reviewed by hand and as they fully control their env, they can stick on the older version until they updated their packaging scripts. What would they do when this would be really a new major-version, whine that their script can't handle it? Btw. many packaging systems can be handled by cmake (which would also handle the changed name) so maybe they rethink their old-fashioned stuff completely.

* Libraries that load zlib dll via dlopen (like OpenSSL!!) - will have to change too. OpenSSL offers a compile-time toggle for the expected DLL name, but does not seem to support it trying multiple names until it finds one that works. Again, bundling `zlib1.dll` would solve this too.

If you use this toggle, you should be able to set it to right name to use. And if you updated zlib you should know that, otherwise you should rethink your update strategy.

You've seen that there is a zlib1.dll in cmake aswell?
Dropping another You've seen that there is a zlib1.dll?

I've gone over this thread a couple of times, then went to see the code, and this was not particularly evident. Now, the code I can understand, the rude comment not so much. Please allow me to try re-word your message in a way that I hope is what you actually meant:

We have left an alternative CMakeLists that generates zlib1.dll instead, please see contrib/zlib1-dll/CMakeLists.txt. Alternatively, you may wish to enable the ZLIB_BUILD_ZLIB1_DLL option in the root CMake so that the zlib1.dll is also produced on Windows.

Only instead of also, but yes.

I think it goes without saying that zlib is one of the most used libraries. A change like this can be very disruptive, especially as the release notes make absolutely no mention of this at all, and zlib itself has a very good tradition of not breaking anything across releases, and this makes a departure from the tradition.

Right, the release notes should be clearer on this (or the README-cmake.md at least). The tradition itself is not at disposition at all. This is a one-time-change to make life for everyone easier. You mentioned the resources and openssl. If openssl can now drop the toggle and the heuristics in the code, the resources shrink. Yes it's maybe 30 lines of code, but multiplied with every future release and every pull or fork or download of the code they sum up over time, just because they now can rely on how the lib is named, regardless of the system.

Thanks @luau-project as I can see you've taking quite some time to report this and reason this - I wish most of the issue reports in the repositories I manage where as nicely detailed.

Regarding reports of crashes, build-failures etc. I can absolutely agree with this. For this one a simple "It was... It is now.... Why?" would have been enough, as it took quite some time to read all this to see if there's more inside.

[jcar87]

I can raise an eyebrow to a DLL/solib change, but it's nothing I haven't seen before.

I am, however, baffled at the hostile response. You seem unaware of how this library is built, bundled or used by the wider community, are making maximalist assumptions about how people may or may not use CMake or makefiles, wrongly assuming that everyone is in a position to easily rebuild everything from source, and seem perfectly content with everyone else dealing with the consequences of a breaking change.

If this change had happened on Linux shared library names, this issue would have far more involvement from distro/repository maintainers
I dont think this makes anything easier other than from the perspective of the author of the CMakeLists.txt - this adds yet another windows DLL name to an already unusual history of DLL names for zlib.

It's hard to engage with that attitude and I will refrain from doing so in the future. I suspect more people will chime in over time explaining how they've been affected, and that repository maintainers that build zlib from source on Windows with CMake will just opt to continue distributing zlib1.dll.

[Vollstrecker]

I am, however, baffled at the hostile response. You seem unaware of how this library is built, bundled or used by the wider community, are making maximalist assumptions about how people may or may not use CMake or makefiles, wrongly assuming that everyone is in a position to easily rebuild everything from source, and seem perfectly content with everyone else dealing with the consequences of a breaking change.

So if you are not in a positionto rebuild from source, why should you update a dependency instead of waiting that someone who is able provides you new binaries. Beside the fact that you could build zlib1.dll or just rename the new one.

If this change had happened on Linux shared library names, this issue would have far more involvement from distro/repository maintainers I dont think this makes anything easier other than from the perspective of the author of the CMakeLists.txt - this adds yet another windows DLL name to an already unusual history of DLL names for zlib.

If this would happen on Linux distros, maintainers would provide a symlink to the old name and be done, as ABI is still compatible. Instead conan chooses to just rename that stuff with a patch.

It's hard to engage with that attitude and I will refrain from doing so in the future. I suspect more people will chime in over time explaining how they've been affected, and that repository maintainers that build zlib from source on Windows with CMake will just opt to continue distributing zlib1.dll.

Example of conan above: They could have choosen to copy the file so people can transition, but they choose to actively surpress their users to transition to the new name and to change away from conan to any other packagemanager that allows transitioning.

[luau-project]

You seem unaware of how this library is built, bundled or used by the wider community, are making maximalist assumptions about how people may or may not use CMake or makefiles, wrongly assuming that everyone is in a position to easily rebuild everything from source, and seem perfectly content with everyone else dealing with the consequences of a breaking change.

Expanding on jcar87 comment

Even though I'm not the highest skilled person building software in the world, everyone used to build cross platform projects from source will follow standard patterns in different operating systems:

• On Unix, whenever a configure script is available, you often run the following script in the source tree:

  ./configure
  make
  make install

• On Windows:

  • In case a top level CMakeLists.txt exists, we run:

    cmake -G "<some generator of your choice>" ^
        -DCMAKE_BUILD_TYPE=Release ^
        -DBUILD_SHARED_LIBS=ON ^
        --install-prefix "<some absolute location>" ^
        -S "<source dir>" ^
        -B "build-dir"
    cmake --build "build-dir" --config Release
    cmake --install "build-dir" --config Release

  • Otherwise, if the developer likes meson and meson.build exists, he\she runs:

    meson setup --prefix "<some absolute location>" "build-dir" "<source dir>"
    meson compile -C "build-dir"
    meson install -C "build-dir"

Nowadays, with a very few parameter deviation, this is the common sense, regardless Vollstrecker, jcar87 or my personal tastes, period. Developers only resort to Makefile-based builds when none of the options mentioned above is available.

Warning

From now on, most Windows developers will build zlib applying the CMake some pattern that resembles the one above, and the unexpected z.dll (or libz.dll) is going to widespread pretty quickly due the massive zlib adoption. So, in a short period of time, there will be two dll names floating around (the previous zlib1.dll and the current z.dll or libz.dll).

As a consequence of the new behavior, I suspect such CMake change on this patch release has the potential to break (what's worse, in runtime) all OpenSSL versions released so far on Windows, as long as the user building OpenSSL passes zlib-dynamic to its configure script.

PS

I apologize for being repetitive, but this is an inappropriate change for a patch release, because a patch release signals, like the name suggests, it is a release meant to fix bugs in the previous version, as opposed to bring important changes.

Note

Through GitHub blame's feature on CMakeLists.txt, it can be seen that Vollstrecker wrote most of it, and we all appreciate his work to improve a 30 years+ project, which has to be stable even at dll names. We are not criticizing his work, we are just reporting a mismatch behavior grounded on zlib's own project files and a DLL FAQ lasting decades.

Most of us know very well that the process to change a DLL name in a CMake script (CMakeLists.txt) and subsequent files is not a hard task. In my opinion, in case it is a valid possibility, it would be more profitable to discuss the challenges to implement a rollback to the DLL name change properly.

[Vollstrecker]

  * In case a top level `CMakeLists.txt` exists, we run:
    cmake -G "<some generator of your choice>" ^
        -DCMAKE_BUILD_TYPE=Release ^
        -DBUILD_SHARED_LIBS=ON ^
        --install-prefix "<some absolute location>" ^
        -S "<source dir>" ^
        -B "build-dir"
    cmake --build "build-dir" --config Release
    cmake --install "build-dir" --config Release
  * Otherwise, if the developer likes `meson` and `meson.build` exists, he\she runs:
    meson setup --prefix "<some absolute location>" "build-dir" "<source dir>"
    meson compile -C "build-dir"
    meson install -C "build-dir"

Nowadays, with a very few parameter deviation, this is the common sense, regardless Vollstrecker, jcar87 or my personal tastes, period. Developers only resort to Makefile-based builds when none of the options mentioned above is available.

Beside my opinion that BUILD_SHARED_LIBS was the worst design-decision. Which one of these commands doesn't work with zlib atm.? In the case of this lines everything will work as expected, as you'll end up with shared and static lib as zlib ignores BUILD_SHARED_LIBS (the same as the cited libpng also does btw.) and so everything afterwards will build without any change.

Problems only occur when you i.e. -DZLIB_BUILD_STATIC=OFF, then you have to change your find_package(ZLIB CONFIG) to find_package(ZLIB CONFIG COMPONENTS shared). If you use find_package(ZLIB) or FindZLIB (the first one uses the second one by default) also nothing change. This change only affect users that indicate they want to use the config, as they have to specify what they want to use if not everything is available (what they also have choosen).

From now on, most Windows developers will build zlib applying the CMake some pattern that resembles the one above, and the unexpected z.dll (or libz.dll) is going to widespread pretty quickly due the massive zlib adoption. So, in a short period of time, there will be two dll names floating around (the previous zlib1.dll and the current z.dll or libz.dll).

If most Windows developers adopt this, then only few the not well maintained projects with hardcoded libnames will expect z.dll. So in year you can see with a search for z.dll what software that is. Maybe to help them, as they seem to need more devs, or to look for alternatives. Another Benefit.

As a consequence of the new behavior, I suspect such CMake change on this patch release has the potential to break (what's worse, in runtime) all OpenSSL versions released so far on Windows, as long as the user building OpenSSL passes zlib-dynamic to its configure script.

Only IF the user install prebuild OpenSSL which has a suitable zlib in it, and replaces it with a selfcompiled version. I'm pretty sure if there are precompiled versions with newer zlib are created, they will take care to use the right one.

I apologize for being repetitive, but this is an inappropriate change for a patch release, because a patch release signals, like the name suggests, it is a release meant to fix bugs in the previous version, as opposed to bring important changes.

I also apologize for being repetetive, but this change is (when adoption spreads) a benefit for everyone, because you'll need less code to detect what you need and be sure what you compile against. And there are no other changes that justify a new major release. Given that you basically understand the reasoning (someone here signaled he does) and (not sure) see's the benefits, how long do you want to wait for the benefits to reach you, as the last major version change was 15 years ago and there is no reason for another one seeable.

Furthermore I'm pretty sure a new major version just because of these changes would cause even more confusion, as only a minority of users are really (not only theoretically) affected.

Note

Through GitHub blame's feature on CMakeLists.txt, it can be seen that Vollstrecker wrote most of it, and we all appreciate his work to improve a 30 years+ project, which has to be stable even at dll names. We are not criticizing his work, we are just reporting a mismatch behavior grounded on zlib's own project files and a DLL FAQ lasting decades.

Thanks. So there would be no critics if Makefile would also change? Btw. DLL_FAQ mentions also the change of name from 1.1.4, and we are still on the same major version.

Most of us know very well that the process to change a DLL name in a CMake script (CMakeLists.txt) and subsequent files is not a hard task. In my opinion, in case it is a valid possibility, it would be more profitable to discuss the challenges to implement a rollback to the DLL name change properly.

Nice idea, but given how often releases happen, this would cause another year of waiting. And if you watch this and the other issues that came up after the release, I'm pretty sure this discussion would be between 3 people and all others come again after the next release -sad but true. As these changes happend some time before the release, you see this is not unreasonable speculation.