编译libcurl with openssl + zlib (gzip)_libcurl --with-zlib-CSDN博客

本文链接：https://blog.csdn.net/sevendemage/article/details/136599451

libcurl 编译说明

libcurl 正常不依赖第三方库也可以进行编译使用，但是只能访问不带ssl通道的http,不能访问https，而且不支持gzip
一般现在常用的https中的ssl是使用openssl、gzip使用zlib
下面是如何编译libcurl，我们在项目中使用的是第二种方式，VC项目的方式。

zlib编译

cd $zlibdir
nmake -f win32/Makefile.msc
在这里插入图片描述

openssl编译

openssl 编译

构建编译环境

将openssl的include与lib和zlib的include与lib分别拷贝到curl平级目录中，类似下图中的目录结构，我这边编译是生成一个总的curl库，zlib与openssl以静态库的方式打包进libcurl的库中。
在这里插入图片描述

在这里插入图片描述

本地curl命令行编译

cd  $curldir/winbuild
nmake /f Makefile.vc mode=dll DEBUG=no ENABLE_UNICODE=yes WITH_SSL=static WITH_ZLIB=static ZLIB_PATH=D:\SevenWorkSpace\Curl_workspace\zlib SSL_PATH=D:\SevenWorkSpace\Curl_workspace\openssl

生成在
在这里插入图片描述

本地Curl VC项目编译

在这里插入图片描述

编译后生成在
在这里插入图片描述

总结与经验
经过对比和测试，这两种编译出来的库都可以正常进行使用，但是由于编译时输入的编译器参数不同，还是需要特殊进行考虑使用方式。
我这边之前的项目中是使用的第二种方式进行的编译，所以后续在这次添加gzip使用时没有使用第一种编译方式生成的库。
由于在网上找到的都是第一种方式编译出来的发现编译后的库文件比较小，如图：
在这里插入图片描述

对比了编译时的命令行，发现很多编译器相关的选项并不一致，并且实际命令行编译后的动态库会多一个调试标记，所以考虑再三还是延续老的方式（VC项目）进行编译。不过测试使用时两种编译方式编译出来的库都可以正常使用。
通过抓取命令行与实际VC项目中的编译选项，分析makefile中ZLIB相关的编译选项，
发现ZLIB源码端启用是多开启了三个宏定义
在这里插入图片描述