基于MSys2+MinGW64使用Conan2编译OpenSSL问题的解决

前言

用了二十多年C/C++，一直在各种平台上编译各种库，一直被C/C++依赖库的管理困扰，自已也开发过一些简单的库管理软件，但也一直不理想，这两天发现conan2可用于管理依赖库，还可以建私服务，初步学习了一下还是比较不错，目前还在学习评估中，试着应用于一些简单开发项目中。

于是在Linux环境、WSL环境中试用都比较顺利，但在Window平台上用MSys2+MinGW64时在编译openssl库时出现问题，编译不通过，各种搜索，资料也比较少，于是研读Conan2官方文档与实验终于解决，于是记录并分享出来。

关于Conan2的简单介绍

Conan2是一个开源的C/C++依赖库管理系统，基于Python3环境运行，通过一个conanfile.txt或Conanfile.py文件定义应用程序的依赖，再通过conan命令进行依赖库的递归下载（从开放的conan.io或自建私服），conan2会自动判断依赖库及递归依赖库是否有对应平台的二进包，如有则会直接下载二进制包到本地缓存库中，没有则会下载依赖库的源码在当前环境下进行源码编译，并将结果打包进本地缓存库中。

conan2只是管理依赖库，构建与编译还是用其它系统完成的，目前支持主流的构建与工具链，本人当前用的是CMake+GCC，Conan2会生成CMakefile附加文件来帮助CMake时能正确关联到所有依赖库。

关于Conan2的具体内容不在本文叙述，可学习官方文件学习探索。

Window平台下基于Msys2+MinGW64的问题与分析

本人测试环境为Window10，安装了Msys2与MinGW64，以及python3和conan2。利用Conan2管理应用程序依赖库，因为应用程序依赖了openssl库，因此在通过Conan2安装依赖库时发现几乎所有依赖库都要重新从源码进行重编译，大概了解了一下，Conan对MinGW的支持并不像其它纯粹点平台支持的好。

本人是用Msys2环境进行测试，即打开“Msys2 MinGW 64位”终端，该终端为类Linux环境。Conan2在安装到OpenSSL依赖包时会从OpenSSL官网或GitHUB上自动下载OpenSSL源码及其所依赖的zlib库源码到本地缓存目录并进行编译，在编译时出现如下编译错误：

gcc  -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include  -DAES_ASM -DBSAES_ASM -DCMLL_ASM -DECP_NIS
TZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL
_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPADLOCK_ASM -DPOLY1305_ASM -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DWHIR
LPOOL_ASM -DX25519_ASM -m64 -m64 -O3 -m64 -O3 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/e/conanhome/p/b/opens991128f6e5efe/p/
res\"" -DENGINESDIR="\"//lib/engines-3\"" -DMODULESDIR="\"//lib/ossl-modules\"" -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D
_MT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -DNDEBUG -I/e/conanhome/p/b/zlibf53b7694a257a/p/include -DNDEBUG -MMD -MF cryp
to/bio/libcrypto-lib-bss_log.d.tmp -MT crypto/bio/libcrypto-lib-bss_log.obj -c -o crypto/bio/libcrypto-lib-bss_log.obj crypto
/bio/bss_log.c
crypto/bio/bss_dgram.c: In function ‘pack_local’:
crypto/bio/bss_dgram.c:1178:13: error: ‘struct in_pktinfo’ has no member named ‘ipi_spec_dst’
 1178 |         info->ipi_spec_dst      = local->s_in.sin_addr;
      |             ^~
make[1]: *** [Makefile:6030: crypto/bio/libcrypto-lib-bss_dgram.obj] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/e/ConanHome/p/b/opens991128f6e5efe/b/src'
make: *** [Makefile:2523: build_sw] Error 2

openssl/3.2.1: ERROR:
Package 'e8e5e4e3ee8592d9f3e31fd47e2534f7f6805a60' build failed
openssl/3.2.1: WARN: Build folder E:/ConanHome/p/b/opens991128f6e5efe/b/build-release
ERROR: openssl/3.2.1: Error in build() method, line 534
        self._make()
while calling '_make', line 526
        self._run_make()
while calling '_run_make', line 503
        self.run(" ".join(command), env="conanbuild")
        ConanException: Error 2 while executing

关于这个错误，在网上查了一下，资料不多，主要分析的原因是由于编译时用了Msys2自已的GCC编译导致，如用MinGW64的GCC就不会有这个问题。

基于这个思路本人研究了一下conan2依赖库管理的一些肤浅的原理，并从GitHub上下载了OpenSSL的recipe文件学习了一下，发现OpenSSL的recipe中定义了会依据平台的不同采用不同的编译方案，在Window平台中会采用MSVC与MSYS进行编译，本测试中conan识别到GCC因此采用了MSys2方式，OpenSSL库的conanfile.py中定义了编译时工具依赖为msys2/cci.latest。在该方式中编译OpenSSL时，conan会先从conan.io服务器上下载msys2/cci.latest自已构建一个Msys2的环境（但本人没有理解conan是如何实现的），因此，在编译OpenSSL时所使用的GCC为这个自建的Msys中的GCC，从而导致编译问题。

解决方案

本人运行conan2的环境就是msys2，并且也安装了MinGW64工具链，本人的解决思路是如何让conan2在编译OpenSSL依赖库源码时不自建msys2环境，而直接采用我的msys2环境。

因此，我从GitHub上下载了OpenSSL的Recipe目录（GitHub - conan-io/conan-center-index: Recipes for the ConanCenter repository），准备自已重新生成一个conan2的Package放到本地缓存存中。

下载下来的Recipe目录内容如下所示：

打开 conanfile.py 文件修改如下图所示部分：

即，不使用msys2/cci.latest环境，其中self.win_bash设为False。另外，强制设置个版本，也可从conan命令行传入。

 上述修改完成后即可开始通过conan命令创建新包到本地缓存中，用于应用程序使用。

nicky@DESKTOP-MFAG6LA MINGW64 /e/Projects/conan-learn/openssl-3.2.1
$ conan create . --build=missing

到此，OpenSSL的编译都正常，但在包测试环节又出现问题，如下图所示：

这个问题我猜测可能是msys2环境不是纯粹的Linux环境所致，此问题可通过修改Recipe目录中test_package目录下的conanfile.py文件解决，如下所示：

修改完成后运行 “$ conan create . --build=missing” 可正常完成编译与测试。