libzip can use several different crypto libraries, and checks their availability by default. It then processes this information in a certain order, and uses the first of these libraries that are have been found.
We always want to use the Windows cryptography library (bcrypt), so we ensure that only support for this is enabled.
I noticed this problem when checking an older build log of libzip, where apparently an OpenSSL library installed on the build runner had been found. This is not an issue per se, since later Windows crypto is checked prior to OpenSSL, but if that order ever changes in the future, or a common crypto library would be detected, the build would not produce the desired results.
libzip can use several different crypto libraries, and checks their availability by default. It then processes this information in a certain order, and uses the first of these libraries that are have been found.
We always want to use the Windows cryptography library (bcrypt), so we ensure that only support for this is enabled.
I noticed this problem when checking an older build log of libzip, where apparently an OpenSSL library installed on the build runner had been found. This is not an issue per se, since later Windows crypto is checked prior to OpenSSL, but if that order ever changes in the future, or a common crypto library would be detected, the build would not produce the desired results.