Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

actions: bump zlib to v1.3, set CMAKE_MSVC_RUNTIME_LIBRARY #725

Merged
merged 1 commit into from
Sep 7, 2023
Merged

Conversation

LDVG
Copy link
Contributor

@LDVG LDVG commented Sep 7, 2023

Since v1.3, zlib advertises compatibility with CMake 3.15 which introduced policy CMP0091 1. The NEW behavior is to to leave the MSVC runtime library selection flags out of the default CMAKE_<LANG>_FLAGS_<CONFIG> values and instead offer a first-class abstraction: MSVC_RUNTIME_LIBRARY 2.

CMP0091 is documented to default to the OLD behavior and not warn when unset. The zlib CMakeLists.txt does not set this policy. However, when building libfido2 as a static library targeting Win32, linking fails because our runtime selection flags for zlib have been replaced from under our feet (the MSVC_RUNTIME_LIBRARY property defaults to the dynamically linked runtime).

Setting -DCMAKE_POLICY_DEFAULT_CMP0091=OLD 3 on the command line has no effect and CMake instead warns that the variable has been ignored. Manually modifying zlib's CMakeLists.txt to set the policy to OLD issues a deprecation warning but fixes our linking issues.

The only remaining possibility that does not modify external files, is to explicitly set -DCMAKE_MSVC_RUNTIME_LIBRARY=... 4 on the command line. Setting it to an empty value does not work (Visual Studio generators may supposedly also override with another default). Setting it to one of the allowed values corresponding to the selected build type resolves our linking issues.

Footnotes

  1. https://cmake.org/cmake/help/latest/policy/CMP0091.html

  2. https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html

  3. https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html

  4. https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html

Since v1.3, zlib advertises compatibility with CMake 3.15 which
introduced policy CMP0091 [1]. The NEW behavior is to to leave
the MSVC runtime library selection flags out of the default
CMAKE_<LANG>_FLAGS_<CONFIG> values and instead offer a first-class
abstraction: MSVC_RUNTIME_LIBRARY [2].

CMP0091 is documented to default to the OLD behavior and not warn when
unset. The zlib CMakeLists.txt does not set this policy. However, when
building libfido2 as a static library targeting Win32, linking fails
because our runtime selection flags for zlib have been replaced from
under our feet (the MSVC_RUNTIME_LIBRARY property defaults to the
dynamically linked runtime).

Setting -DCMAKE_POLICY_DEFAULT_CMP0091=OLD [3] on the command line has
no effect and CMake instead warns that the variable has been ignored.
Manually modifying zlib's CMakeLists.txt to set the policy to OLD issues
a deprecation warning but fixes our linking issues.

The only remaining possibility that does not modify external files,
is to explicitly set -DCMAKE_MSVC_RUNTIME_LIBRARY=... [4] on the
command line. Setting it to an empty value does not work (Visual Studio
generators may supposedly also override with _another_ default). Setting
it to one of the allowed values corresponding to the selected build type
resolves our linking issues.

[1] https://cmake.org/cmake/help/latest/policy/CMP0091.html
[2] https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html
[3] https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html
[4] https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html
@LDVG LDVG requested a review from kongeo September 7, 2023 08:01
@kongeo kongeo merged commit 26e792c into main Sep 7, 2023
73 checks passed
@kongeo kongeo deleted the zlib-ci branch September 7, 2023 15:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants