#1181·zlib

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

Author: luau-projectCreated Feb 21, 2026Updated Sep 20, 2026

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 (https://github.com/madler/zlib/pull/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

https://github.com/madler/zlib/blob/da607da739fa6047df13e66a2af6b8bec7c2a498/CMakeLists.txt#L157-L160

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

https://github.com/madler/zlib/blob/da607da739fa6047df13e66a2af6b8bec7c2a498/win32/zlib1.rc#L22-L31

[!NOTE]

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

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
yaml
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)