Redis编译后找不到生成文件，搞不懂到底哪里出错了

那天我在自己的电脑上折腾Redis，想从源码编译安装一个最新版本，整个过程听起来很简单，对吧？就是那种经典的“三步走”：下载源码包，解压，然后进入目录执行make命令，我信心满满地打开了终端，一行行命令敲下去，编译过程看起来也非常顺利，屏幕上飞快地滚过各种编译信息，最后似乎安静地结束了,没有看到刺眼的错误提示。

我以为大功告成了，接下来就该是make install了，但就在我准备进行下一步之前，习惯性地想先用ls命令看看生成了哪些东西，特别是那个最重要的redis-server可执行文件，奇怪的事情发生了：目录里除了我之前看到的src、tests、utils这些源码文件夹，以及Makefile、README.md等配置文件，压根就没有任何新出现的、看起来像是编译产出的可执行文件或者大型库文件。

我愣了一下，心想：“难道我眼花了？还是命令根本没执行成功？”我重新检查了一遍，确认自己确实是在解压后的Redis源码根目录下，我又特意进入到src子目录里看了看，里面也依然是源码文件（.c文件等），并没有想象中的redis-server或redis-cli，这下我彻底搞不懂了，明明编译过程看起来一帆风顺，怎么就像什么都没发生一样？生成的文件到底藏到哪里去了？还是说哪个环节出了错,但我没注意到？

我开始有点烦躁，感觉像是被戏弄了，于是我不死心，决定从头再来一遍，我删除了整个解压出来的目录，重新解压了一份全新的源码，这次我更加小心翼翼，我再次执行make命令，并且这次我瞪大了眼睛，紧紧盯着屏幕上的每一行输出，编译信息再次快速滚动，我努力捕捉任何可能的问题线索，终于，在信息的末尾，我似乎瞥见了一行不太一样的提示，但滚得太快,没看清具体内容。

这次我学聪明了，没有直接去ls，而是先输入了echo $?来查看上一条命令（也就是make）的退出状态码，结果是0！在Linux世界里，退出状态码为0通常意味着命令成功执行，这反而让我更困惑了：既然系统都告诉我成功了，那为什么找不到文件呢？难道Redis的编译流程比较特殊,生成的文件放在了某个我意想不到的隐蔽位置？

带着这个疑问，我决定仔细阅读Redis源码自带的README.md文件，也许里面有关于编译和输出的说明，果然，在README中，我找到了关键信息！文件里明确写着：“编译完成后，所有可执行文件都会在src目录下生成。” 我之前的判断是对的，文件确实应该在src里,但我第一次查看时为什么没看到？

我立刻再次进入src目录，这次我使用了ls -l命令，以详细列表的形式显示所有文件，包括隐藏文件，列表里依然主要是.c、.h等源码文件，正当我快要放弃的时候，我下意识地输入了file redis-*，想看看有没有以redis-开头的文件是什么类型，就是这一个操作，真相大白了！系统提示我：redis-*: No such file or directory，这说明连模糊匹配都找不到任何以redis-开头的文件。

这下问题严重了，说明编译过程确实没有生成目标文件，我不得不面对现实：编译一定是在某个环节出错了，尽管make命令的退出码是0，而且屏幕输出看起来正常，我决定第三次运行make，但这次我要把所有的输出信息都重定向到一个文本文件里，然后仔细检查，我用了命令make > build.log 2>&1，这样就能把标准输出和错误输出都保存到build.log文件中。

打开这个日志文件，我逐行仔细检查，前面大段的编译信息确实都正常，.c文件都被cc编译器处理了，生成了对应的.o目标文件，在接近末尾的地方，我发现了问题！有几行链接命令（通常是以cc -o开头，用于将多个.o文件链接成最终的可执行文件），其后面跟着大量的错误信息，核心关键词是undefined reference to ...，意思是“未定义的引用”。

这些“未定义的引用”指向的都是一些函数名，这些函数看起来是某种加密或者哈希相关的功能，我瞬间明白了：我的系统缺少了编译Redis所需的某个依赖库！Redis在最终链接生成可执行文件时，需要调用系统上的某些库函数，而我的开发环境可能不完整，缺少了对应的库文件（后来知道可能是libcrypto之类的），导致链接器无法找到这些函数的具体实现，所以最终的可执行文件redis-server和redis-cli根本就没能成功生成出来。

这就是为什么make过程看似“成功”了——因为编译（从.c到.o）这一步确实是成功的，所以make工具可能认为任务完成了很大一部分，甚至可能忽略了链接阶段的致命错误，或者将其视为非致命警告，从而返回了成功退出码0，但实际上，最关键的链接步骤失败了，导致功亏一篑,自然也就找不到生成的可执行文件。

问题的根源终于找到了，不是我操作步骤的问题，而是系统环境缺失了必要的开发库，解决起来就相对简单了，我根据错误信息提示的函数名，通过系统包管理器搜索并安装了对应的开发包（例如在Ubuntu上可能是libssl-dev），再次执行make clean清理掉之前编译的中间文件，然后重新make，这次就一切正常了，编译结束后，我再次进入src目录，熟悉的redis-server和redis-cli等文件终于安静地躺在那里了。

这次经历让我深刻体会到，在Linux下从源码编译软件，看似简单的命令背后，可能隐藏着依赖库的陷阱，屏幕输出看似正常甚至命令返回成功码，也未必代表真的完全成功，遇到“找不到生成文件”这种诡异情况，一定要耐心地、想方设法地去查看完整的、详细的日志信息，特别是链接阶段的错误,那往往是问题的关键所在。