Redis编译报错了，折腾半天找原因和解决办法分享

（来源：知乎用户“码农小张”的分享）前几天我在自己电脑上编译Redis的时候，碰到了一个特别磨人的错误，折腾了快一个下午才解决掉，我觉得这个过程可能对其他人也有帮助,所以就把前因后果和解决办法记下来。

我的环境是Ubuntu系统，想编译安装一个比较新的Redis版本，按照网上最常见的教程，步骤看起来特别简单：先下载源码包，然后解压，接着进入解压后的目录，输入make命令就开始编译了。

一开始都很顺利，直到make命令执行了一会儿之后，突然就停住了，然后报出了一大片红色的错误信息，我当时心里就“咯噔”一下，心想：“完了，又碰上幺蛾子了。”

（来源：错误日志截图）错误信息的核心部分大概是这样的：

cc: error: ../deps/hiredis/libhiredis.a: No such file or directory
cc: error: ../deps/jemalloc/lib/libjemalloc.a: No such file or directory

还有一些关于找不到jemalloc这个库的链接错误。

我看到错误的第一反应是，是不是我漏掉了什么步骤？比如需要先安装什么依赖库？于是我重新去翻看Redis源码包里附带的README.md文件，里面确实提到了需要安装一些基础编译工具，比如gcc、make之类的,但这些我早就装好了。

然后我又想，是不是jemalloc这个内存分配器没装？我尝试用apt命令去安装libjemalloc-dev，但系统提示我已经是最新版了，这就很奇怪了，明明系统里有,为什么编译的时候还是找不到呢？

（来源：Redis GitHub仓库的Issue讨论）我在网上搜了半天，关键词就是那个错误信息“cc: error: ../deps/hiredis/libhiredis.a: No such file or directory”，果然，在Redis的GitHub项目Issues里，找到了很多有类似问题的人，翻了好几个帖子，终于发现了一个关键线索：这个问题经常出现在尝试第二次或者第N次编译的时候。

我仔细回想了一下，还真是！我之前确实因为想换版本，在这个目录下编译过一次旧版本的Redis，虽然我把旧的源码目录删了，重新解压了新版本，但可能有一些中间文件残留，或者编译状态被缓存了,导致了冲突。

（来源：Stack Overflow上一个高赞回答）有一个回答直接指出了解决办法：先执行一下make distclean，然后再执行make。

我抱着试一试的心态，在编译目录下输入了make distclean，这个命令运行了一会儿，看起来是在清理之前编译生成的各种中间文件和目标文件，清理完成后，我再次输入make。

神奇的事情发生了！编译过程重新开始，这一次非常顺畅，之前那个找不到libhiredis.a和libjemalloc.a的错误没有再出现，一路编译成功，最后看到了令人欣慰的“Hint: It's a good idea to run 'make test' ;)”提示。

（来源：个人总结）事后我琢磨了一下这个问题的原因，Redis的编译系统（就是那个Makefile）为了加快编译速度，可能会跳过一些已经编译过且认为没有变化的依赖项，如果你之前编译过，但中途失败了，或者像我先编译了旧版本又换新版本，编译系统可能就会“犯糊涂”，它以为那些依赖库（比如hiredis、jemalloc）已经准备好了，实际上它们可能不存在或者版本不对，所以当链接器（就是那个cc）去链接这些库文件时，就找不到它们了,从而报错。

而make clean命令和make distclean命令的区别在于，clean通常只清理核心项目生成的目标文件，而distclean会清理得更彻底，包括所有依赖项（deps目录下的）的编译产物，对于这种依赖项出的问题，用distclean才能从根本上解决。

总结一下我的经验教训：

1. 编译失败先别慌，仔细读错误信息,核心线索往往就在那一两行里。
2. 善用搜索引擎，把你看到的错误信息直接复制上去搜，很大概率别人已经遇到过了，优先看官方项目的Issues和Stack Overflow上的回答。
3. 对于Redis编译，如果遇到类似的链接库找不到的错误，尤其是涉及deps目录下库文件的，优先尝试make distclean彻底清理，然后再重新make,这能解决大部分因残留文件导致的编译问题。
4. 如果make distclean还不行，那可能就需要更彻底的清理，比如删除整个源码目录，重新解压一份全新的源码,再从头开始编译。

这次折腾虽然花了些时间，但也让我对编译过程的清理环节有了更深的理解，算是意外收获吧,希望这个经历能帮到遇到同样问题的朋友。