Build files: consistency of binaries names on Windows between CMakeLists and Makefiles

[SpaceIm]

For Windows builds, zlib provides 4 build files:

• Makefile.gcc for MinGW
• Makefile.msvc and MSBuild files for Visual Studio
• CMake

For a given compiler, names of generated binaries are not consistent among these build systems:

MinGW:

build file	static	shared (import lib & dll)
Makefile.gcc	libz.a	libz.dll.a & zlib1.dll
CMakeLists.txt	libzlibstatic.a	libzlib.dll.a & libzlib1.dll

Visual Studio:

build file	static	shared (import lib & dll)
Makefile.msvc	zlib.lib	zdll.lib & zlib1.dll
MSBuild	zlibstat.lib	zlibwapi.lib & zlibwapi.dll
CMakeLists.txt	zlibstatic[d].lib	zlib[d].lib & zlib[d]1.dll

Wouldn't it be better to follow Makefiles names in CMakeLists.txt? What is considered canonical name for each compiler?

[jheaff1]

Further to what is described above, when building static zlib using CMake on Windows, the output lib (zlibstatic.lib) does not match what is described in the pkg-config .pc file. As such, if a dependent library were to use pkg-config to resolve a statically built zlib on Windows, it would fail

[madler]

Do you or anyone else here have an opinion on what those names should be?

[jheaff1]

I’m personally not bothered about naming inconsistencies, as long as usage of the pkg-config .pc file works

[vszakats]

With MinGW (and MSYS/Cygwin) the expected names are: libz.a for static and libz.dll.a for the implib. These are recognized by the toolchain as static/shared libs when linking.

[Neustradamus]

To follow this ticket

[AraHaan]

Also: building in WSL (ubuntu 22.10 on it) fails to run ./configure as well.

Likewise, I have a situation where I would like to build zlib for linux-x86, linux-x64, linux-arm, and linux-arm64 (all in a x64 build of linux).