一、引言
接触 libcurl 已经有一周了，在这段时间里面，我成功在 Ubuntu18.04 Redhat 7.2 Win10 环境下编译了 libcurl 库，并且使用编译出来的库成功运行了 libcurl 源代码自带的示例代码。
当我今天试图运行一个 https 请求相关的代码时，libcurl 返回了错误码 Unsupported Protocol，于是我在命令行中敲下了如下的一行命令：
$ curl-config --feature
显然，这是我编译的时候没有成功支持 ssl 的问题，于是导致 https 协议无法支持。
解决这个问题的方法很简单，那就是重新编译 libcurl ，使其支持 ssl 即可。
二、问题所在：默认编译居然没有支持 ssl
想要找到一手的解放方法，当然不是搜博客，而是寻找 libcurl 的源代码中的 docs 下的 INSTALL 文档，其中有详细介绍 libcurl 的编译与安装过程：
The configure script always tries to find a working SSL library unless explicitly told not to. If you have OpenSSL installed in the default search path for your compiler/linker, you don’t need to do anything special.
这段话是 INSTALL 文档的原文，我们从源代码编译 libcurl 源代码的时候，第一步就是运行源代码文件中的 configure 指令，而按照这里的意思， configure 脚本文件总会试图去寻找 SSL 库文件，除非用户明确要求禁止 SSL（这一块网上很多博客都是错误的，居然说 libcurl 默认是不支持 SSL 的）。
那么，为什么我按照默认编译的 libcurl 还是没有支持 SSL 呢，原因很简单，因为编译器和链接器找不到我环境中的 SSL 的库文件。
那么我环境中究竟有没有 SSL 库呢？
根据 whereis 命令的反馈，我发现当前环境是有 openssl 工具的。
那么为什么 libcurl 的 configure 工具并没有找到呢？以下说出我的猜测（可能不正确，只是我的推测）：
我猜测，环境中的 openssl 是 Linux 本身自带的，于是乎就去掉了一些编译器和链接器所需要的一些信息，对于用户来说，openssl 是一个工具，但是对于编译链接 libcurl 的任务来说，现在环境中的 openssl 就少了一些信息。
这也就是我猜测的为什么在默认情况下编译的 libcurl 并没有支持 ssl 的原因。
三、问题解决：下载编译 openssl
解决这个问题的方法其实也很简单，那就是重新下载编译 openssl，使其能够提供 libcurl 能够支持 ssl 的一些配置信息。
1. 下载 openssl
openssl 在 linux 下的编译还是很简单的。
OpenSSL Download
2. 解压 openssl
选择图示下载下来，放置到 Linux 环境中去。
$ tar -xvf openssl-1.1.0i.tar.gz3. 查看源代码中的 INSTALL 文档，按照指示步骤编译 openssl
$ ./config
$ make
$ make test
$ make install其中第 3 步可以省略，第 4 步需要 root 权限。
此时，查看 openssl 可以看到变化：
4. 重新编译 libcurl
安装 openssl 结束后，我们重新按照 libcurl 源代码中的 docs 文件夹中的 INSTALL 文件中的指示编译 libcurl 即可：
$ ./configure
$ make
$ make test (optional)
$ make install其中，第 3 步同样是可以省略的，第 4 步同样是需要 root 权限的。
当你运行完第 1 步的时候，也就是 configure 执行完之后，如果 openssl 安装没有问题的话，应该就能看到 SSL 的支持了：
后面，只要 configure 能够成功显示 SSL support 为 enabled，后面的问题也就只剩下编译了。
四、不同平台：Ubuntu 18.04 和 RedHat 7.2 的区别
在写这篇博客的时候，我同时在两个平台上进行了试验，一个是 Ubuntu 18.04，另一个是 RedHat 7.2 环境。
按照上述的步骤，Ubuntu 18.04 应该是没有任何问题的，但是 RedHat 7.2 应该是会出现问题的。比如你在非 openssl 安装目录和非库目录下下运行 openssl 就会出现下列的错误：
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
这是因为 openssl 程序并没有找到正确的支持库 libssl.so.1.1 的位置，那么配置正确即可：
# 需要 root 权限
ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/libssl.so.1.1
ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1也就是说，对于 RedHat 7.2 平台上来说，比 Ubuntu 18.04 就要多一个步骤，就是在安装完 openssl 之后需要配置两个库文件的软性链接，然后再编译 libcurl 库即可，后面的步骤就是一样的了。
ps: 这个问题我排查了好久好久，结果发现原来是 RedHat 7.2 的 openssl 运行就有问题，要不是我在非 openssl 安装目录和非库目录下尝试着运行下 openssl，估计还要在这个问题上徘徊好久 T_T
五、总结
总而言之，Linux 自带的 openssl 是满足不了我们的 libcurl 的开发需求的。因此为了让我们的 libcurl 库能够支持 SSL，我们就需要重新编译安装 openssl。
在重新编译安装 openssl 的过程中，RedHat 7.2 平台需要比 Ubuntu 18.04 平台多做一件事，那就是配置 openssl 的库信息。
不过问题解决的思路总是简单的，就是重新编译安装了下 openssl，再重新编译安装 libcurl。
最后的最后，使用 curl-config --feature 命令，能看到输出来的 SSL，那么我们的任务就算成功完成啦 ^_^
希望这篇博客能够给陷入同样困境的你一些帮助~~~
Enjoy It：）