1. 从一次真实的编译报错说起

那天下午，我正在一台ARM架构的CentOS 8服务器上折腾，目标是把MySQL 5.7.32的源码给编译出来。环境都配置得差不多了，满心期待地敲下cmake .，结果终端里蹦出来几行红字，编译进程戛然而止。其中最扎眼的就是这一句：-- Package 'libtirpc', required by 'virtual:world', not found。紧接着就是CMake的致命错误，提示找不到rpc/rpc.h这个头文件。相信很多朋友在Linux下搞编译，尤其是涉及到一些老一点的项目或者特定架构时，都见过类似“找不到某个包”的报错。但这次报错信息里多了个陌生的角色——virtual:world。这玩意儿是啥？它和libtirpc又是什么关系？为什么在常见的x86机器上编译可能没事，换到ARM服务器上就出问题了呢？

如果你也一头雾水，别急，这恰恰是CMake依赖管理里一个挺有意思的“坑”。这个错误表面上看是缺了一个叫libtirpc的库，但根源远比“缺啥装啥”要复杂。它牵扯到操作系统版本的变迁、软件包管理的差异、跨平台编译的兼容性，以及CMake这个构建系统在寻找依赖时的内在逻辑。简单粗暴地yum install有时候能解决问题，但如果你不明白背后的原理，下次换一个环境，比如Ubuntu或者不同的CentOS版本，可能又会栽在另一个类似的依赖问题上。这篇文章，我就想和你一起，像侦探破案一样，把libtirpc缺失这个问题的来龙去脉彻底捋清楚，并给你一套不仅能解决眼前问题，更能举一反三应对其他CMake依赖问题的高效修复方案。

2. 拆解错误信息：不只是“包未找到”那么简单

面对CMake报错，第一步永远是仔细阅读错误信息。我们遇到的这个错误信息量其实很大，我们来逐句拆解。

### 2.1 核心报错：“Package ‘libtirpc‘, required by ‘virtual:world‘, not found”

这句话是问题的直接导火索。CMake通过pkg-config工具来查找一个名为libtirpc的软件包。pkg-config是Linux下用来管理编译和链接选项的一个小工具，很多库在安装后都会提供一个对应的.pc文件（比如libtirpc.pc），里面写明了这个库的头文件路径、库文件路径以及需要的编译链接参数。

关键点在于required by ‘virtual:world‘。这里的virtual:world并不是一个真实的、你代码里显式依赖的包。它是一个虚拟依赖项，可以理解为一个“元包”或者“依赖集合”。在很多软件包的pkg-config文件（.pc文件）里，会通过Requires:字段声明自己依赖哪些其他包。有些基础性的、被广泛依赖的库，可能会被标记为virtual:world的依赖。这意味着，任何声称依赖virtual:world的包，实际上都间接依赖了libtirpc。在我们的场景里，很可能是MySQL的某个组件（比如报错中提到的group_replication插件）的构建配置，通过CMake间接地触发了对virtual:world的检查，而virtual:world又要求系统必须提供libtirpc。

### 2.2 深层错误：“Could not find rpc/rpc.h”

这是上一个错误的直接后果，也是导致编译失败的真正技术原因。CMake在尝试了常规路径（/usr/include）和一个特殊路径（/usr/include/tirpc）后，都没有找到rpc/rpc.h这个头文件。

rpc/rpc.h是什么？它是远程过程调用相关的头文件，属于一个历史悠久的、被称为“Sun RPC”或“ONC RPC”的编程接口。在很久以前，这个功能是直接集成在Glibc（GNU C库）里的。也就是说，如果你的系统Glibc版本足够老，你可能根本不需要单独的libtirpc库，因为Glibc自带了RPC的实现。

那么问题来了：为什么现在需要单独的libtirpc库了呢？这就引出了我们下一个要探讨的根源性问题。

3. 追根溯源：为什么需要libtirpc？

要理解为什么缺失，得先明白它为什么存在。这背后是一个典型的“历史包袱”和“架构演进”的故事。

### 3.1 Glibc的“瘦身”与功能剥离

大约在Glibc 2.14版本之后，Glibc的开发团队决定将一些历史遗留的、不那么核心的组件从主库中剥离出去，以简化Glibc的维护并提高其可移植性。其中就包括了Sun RPC的实现。这个决定意味着，从某个时间点开始，新版本的Glibc不再提供rpc/rpc.h等头文件和相关的库函数（如libc.so里的RPC符号）。

那么，那些仍然需要RPC功能的旧程序或者依赖RPC的库（比如MySQL中用于组复制的部分功能）该怎么办呢？社区为此创建了一个独立的、替代性的库，它就是 libtirpc。libtirpc的全称是“Transport Independent RPC”，即“传输层独立的RPC”。它实现了之前Glibc内置的RPC接口，并且做了一些改进，比如支持IPv6。它的出现，就是为了填补Glibc剥离RPC功能后留下的空白。

### 3.2 操作系统分水岭：CentOS/RHEL 8 与 Ubuntu 20.04+

这个变化反映到具体的操作系统发行版上，就形成了一个重要的分水岭：

• CentOS/RHEL 7及更早版本，Ubuntu 18.04及更早版本：它们的Glibc版本较老，仍然内置了RPC功能。在这些系统上编译依赖RPC的老软件，通常不会遇到libtirpc缺失的问题，因为需要的头文件和库函数都在Glibc里。
• CentOS/RHEL 8及更新版本，Ubuntu 20.04及更新版本：它们采用了新版的Glibc（>=2.28），RPC功能已被移除。因此，如果你要在这些新系统上编译那些仍然依赖老式Sun RPC接口的软件，你就必须额外安装libtirpc库来提供这些接口。

这完美解释了我们的场景：在ARM架构的CentOS 8上编译MySQL 5.7.32。CentOS 8是新系统，Glibc没有RPC；MySQL 5.7.32虽然不算特别老，但其部分代码（尤其是组复制插件）可能仍在使用传统的RPC接口，或者其构建系统（CMake脚本）是以存在RPC为前提进行检测的。两者一碰撞，依赖缺失的错误就出现了。

### 3.3 ARM架构的特殊性

那为什么在x86_64的CentOS 8上可能没问题呢？这里有时运气的成分。有些软件包在构建时，可能通过更复杂的条件判断规避了这个问题，或者其依赖关系在不同架构的软件仓库中略有不同。但ARM架构作为一种日益流行的服务器平台，其软件仓库的完备性和一些历史遗留包的同步状态，有时可能与x86架构存在细微差异，这使得依赖问题更容易暴露出来。所以，“在ARM上编译遇到怪问题”本身也是一个常见的现象。

4. 高效修复方案：不止于yum install

明白了根源，解决方案就清晰了。但“高效修复”意味着不仅要解决当前问题，还要知道如何验证、如何应对变体问题、以及如何从根本上避免。

### 4.1 方案一：标准安装（针对CentOS/RHEL/Fedora）

对于基于RPM包管理的系统（如CentOS、RHEL、Fedora），修复命令确实很简单：

sudo yum install libtirpc libtirpc-devel
# 或者使用dnf（CentOS 8/RHEL 8默认）
sudo dnf install libtirpc libtirpc-devel

这里有个关键点：必须安装libtirpc-devel。libtirpc包只包含运行时共享库（.so文件），而编译时需要的是头文件（.h）和链接用的库文件（.a或.so的链接信息），这些都在-devel开发包中。只安装libtirpc的话，CMake依然找不到rpc/rpc.h。

安装完成后，你可以验证一下：

# 检查头文件是否存在
ls /usr/include/tirpc/rpc/rpc.h
# 检查pkg-config文件
pkg-config --cflags --libs libtirpc

如果第二条命令能成功输出-I/usr/include/tirpc和-ltirpc之类的信息，就说明安装和配置成功了。此时重新运行CMake，应该就能通过libtirpc的检查。

### 4.2 方案二：APT系列系统（Debian/Ubuntu）的应对

如果你是在Ubuntu 20.04或更新版本上遇到类似问题，包名和命令略有不同：

sudo apt update
sudo apt install libtirpc-dev

在Debian/Ubuntu体系里，开发包通常以-dev结尾，而不是-devel。安装后，同样可以用pkg-config来验证。

### 4.3 方案三：源码编译与自定义路径

在某些极端环境下，比如没有网络权限的离线服务器，或者你需要特定版本的libtirpc，你可能需要从源码编译。

1. 下载源码：你可以从官方的Git仓库或发行版网站获取源码包。
2. 编译安装：

   tar -xzf libtirpc-x.x.x.tar.gz
   cd libtirpc-x.x.x
   ./configure --prefix=/usr/local    # 可以指定安装路径
   make
   sudo make install
   

3. 让系统找到它：如果你安装到了非标准路径（如/usr/local），需要确保CMake或pkg-config能找到它。
   • 方法A：安装时通过./configure --prefix=/usr直接安装到系统标准路径（有风险，可能覆盖系统包）。
   • 方法B：设置环境变量。对于CMake，可以在调用时指定：

     cmake -DCMAKE_PREFIX_PATH=/usr/local ...
     

   • 方法C：告诉pkg-config：

     export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
     

### 4.4 方案四：修改CMakeLists.txt（高级方案）

有时，你可能不想安装系统级的libtirpc，或者你想更精细地控制依赖查找逻辑。这时可以直接修改项目的CMake配置。查看MySQL报错信息中的路径：cmake/rpc.cmake:76。我们可以打开这个文件看看CMake是怎么找RPC的。

通常，这类检查脚本会使用find_package或者find_path、find_library等CMake命令。一个更健壮的查找libtirpc的方式可能如下（你可以尝试将其思想融入原有脚本）：

# 首先尝试通过 pkg-config 查找
find_package(PkgConfig REQUIRED)
pkg_check_modules(PC_TIRPC QUIET libtirpc)

# 设置头文件和库的搜索路径
find_path(TIRPC_INCLUDE_DIR
    NAMES rpc/rpc.h
    HINTS ${PC_TIRPC_INCLUDEDIR} ${PC_TIRPC_INCLUDE_DIRS}
    PATH_SUFFIXES tirpc
    PATHS /usr/include /usr/local/include
)

find_library(TIRPC_LIBRARY
    NAMES tirpc
    HINTS ${PC_TIRPC_LIBDIR} ${PC_TIRPC_LIBRARY_DIRS}
    PATHS /usr/lib /usr/local/lib
)

# 处理找到的结果
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(TIRPC DEFAULT_MSG TIRPC_LIBRARY TIRPC_INCLUDE_DIR)

if(TIRPC_FOUND)
    set(TIRPC_LIBRARIES ${TIRPC_LIBRARY})
    set(TIRPC_INCLUDE_DIRS ${TIRPC_INCLUDE_DIR})
    # 如果使用 pkg-config 获取了编译标志，也可以加上
    if(PC_TIRPC_FOUND)
        set(TIRPC_INCLUDE_DIRS ${TIRPC_INCLUDE_DIRS} ${PC_TIRPC_INCLUDE_DIRS})
        set(TIRPC_LIBRARIES ${TIRPC_LIBRARIES} ${PC_TIRPC_LIBRARIES})
        set(TIRPC_CFLAGS ${PC_TIRPC_CFLAGS_OTHER})
    endif()
    mark_as_advanced(TIRPC_INCLUDE_DIR TIRPC_LIBRARY)
endif()

这种方式会优先使用pkg-config，如果失败，再回退到在标准路径中搜索，并且明确指定了tirpc这个路径后缀，兼容性更好。当然，修改开源项目的构建脚本需要谨慎，最好能向上游提交补丁。

5. 举一反三：如何系统化解决CMake依赖问题

搞定libtirpc之后，我们升华一下，把这类问题的解决思路固化下来，以后遇到任何“Package not found”都能从容应对。

### 5.1 诊断四步法

1. 读错误：仔细看CMake的输出，找到“not found”或“Could NOT find”的关键行。注意看是哪个包、被谁依赖（required by）。
2. 查包信息：用包管理工具搜索。在CentOS上yum search <包名>或dnf search <包名>，在Ubuntu上apt search <包名>。重点找带-devel或-dev后缀的包。
3. 验安装：安装后，验证核心文件是否存在。对于库，通常是：
   • 头文件：在/usr/include或/usr/local/include下找.h文件。
   • 库文件：在/usr/lib或/usr/local/lib下找.so或.a文件。
   • pkg-config文件：在/usr/lib/pkgconfig或/usr/share/pkgconfig下找.pc文件。可以用pkg-config --list-all | grep <包名>查看。
4. 析根源：思考为什么缺。是新旧系统差异？是架构不同？还是项目本身的依赖声明太老？理解根源有助于预防。

### 5.2 理解virtual:world与pkg-config

virtual:world是一个很好的学习案例。它告诉我们，依赖关系可能是间接的、虚拟的。当CMake报出一个你没直接引用的包时，去查一下这个包是谁提供的，以及它被哪些.pc文件所“Requires”。可以使用pkg-config --print-requires <包名>和pkg-config --print-provides来查看依赖关系网。有时候，安装一个提供虚拟依赖的“元包”能一次性解决多个问题。

### 5.3 环境变量是你的利器

CMake查找依赖深受环境变量影响：

• PKG_CONFIG_PATH：告诉pkg-config去哪里找.pc文件。当你把库安装在非标准路径时，必须设置此变量。
• CMAKE_PREFIX_PATH：告诉CMake去哪里查找所有依赖的根目录。这是最常用的自定义路径变量。
• CMAKE_INCLUDE_PATH 和 CMAKE_LIBRARY_PATH：分别指定额外的头文件和库文件搜索路径。

在调用CMake时通过-D选项传递这些变量，比如cmake -DCMAKE_PREFIX_PATH=/opt/mylibs ..，是解决依赖问题的常用手段。

### 5.4 查阅项目的构建文档

最后，也是最靠谱的一步：去看你要编译的项目的官方文档或README.md。好的项目都会明确列出构建依赖（Build Dependencies/Prerequisites）。对于MySQL这样的知名软件，其官方文档里一定有对操作系统和依赖库的详细说明。先满足文档要求，能避免绝大部分问题。

那次在ARM服务器上解决libtirpc问题花了我一些时间，但把整个过程摸透后，感觉像是打通了任督二脉。后来再遇到CMake报找不到libssl、libcurl或者其他什么库的时候，我都不慌了。无非就是沿着“读错误、查包名、装开发包、设路径”这个流程走一遍，核心逻辑都是一样的。编译这件事，很多时候拼的就是对系统环境和构建工具的理解深度。希望这次对libtirpc的深度剖析，能帮你下次在遇到CMake依赖问题时，不仅知道怎么“治标”，更能明白如何“治本”。