Build files: consistency of binaries names on Windows between CMakeLists and Makefiles
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?
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
Do you or anyone else here have an opinion on what those names should be?
I’m personally not bothered about naming inconsistencies, as long as usage of the pkg-config .pc file works
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.
To follow this ticket
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).