CentOS 中 C++ 项目的打包配置指南
在CentOS上部署C++项目，其实并没有想象中那么复杂。关键在于搞清楚自己的交付场景——是内部系统分发，还是离线环境交付，亦或是以SDK形式提供给第三方开发者。确定了场景之后，打包方式自然就有了明确的选择。下面就从三种主流方案入手，逐一拆解具体的配置方法。
方案总览
先梳理一下整体的选项框架：
- 发行版安装包（RPM）：通过SPEC文件描述构建、安装与文件清单，优势在于依赖管理和系统级安装，最适合在CentOS环境内部进行分发和上线操作。
- 便携运行包：将可执行文件与所有依赖库、配置文件、资源文件一起打包成目录或压缩包，配合启动脚本设置LD_LIBRARY_PATH。这种方案最大的好处是离线部署和快速交付时很省心。
- 库产物打包：项目最终输出为静态库（.a）或共享库（.so），供其他工程链接使用。需要正确设置头文件路径和链接参数（-I、-L、-l），这在SDK交付场景中最为常见。
方案一：RPM打包配置
先说说最常见的一种场景：用RPM包直接分发。如果你的项目是部署在公司内部的CentOS服务器上，这几乎是标准做法。
准备构建环境
先把工具链和打包工具安装好：
sudo yum groupinstall "Development Tools"
sudo yum install gcc-c++ cmake rpm-build
组织目录与源码
按照约定，在项目根目录下构建出可执行文件（比如 build/greeter），同时准备好配置文件和文档。
准备打包素材
按照最终的安装结构，在临时目录中摆放文件：
mkdir -p greeter-1.0/usr/bin greeter-1.0/etc greeter-1.0/usr/share/doc/greeter-1.0
cp build/greeter greeter-1.0/usr/bin/
echo "recipient = RPM User" > greeter-1.0/etc/greeter.conf
echo "Greeter App v1.0" > greeter-1.0/usr/share/doc/greeter-1.0/README.md
然后将整个目录打包成源码包，放到rpmbuild的SOURCES目录下：
tar -czvf greeter-1.0.tar.gz greeter-1.0
mv greeter-1.0.tar.gz ~/rpmbuild/SOURCES/
编写SPEC文件
SPEC文件是RPM打包的核心。需要包含以下关键内容：
- 基本信息：Name、Version、Release、Summary、License、URL、Source0都必不可少。
- 依赖与架构：例如 Requires: libstdc++，BuildArch: x86_64（按实际架构填写）。
- 构建安装阶段：%prep用于解压，%build在预编译二进制场景下可以为空。%install阶段需要用install命令将文件安装到%{buildroot}对应的目录，比如%{_bindir}、%{_sysconfdir}、%{_docdir}。
- 文件清单：%files部分声明需要包含的文件及其权限。配置文件建议用%config(noreplace)来避免升级时覆盖用户修改过的内容，必要时用%attr明确指定权限。
- 变更日志：%changelog部分记录版本历史。
构建与验证
执行构建命令：
rpmbuild -bb ~/rpmbuild/SPECS/greeter.spec
产物在 ~/rpmbuild/RPMS/x86_64/ 目录下。验证环节建议做以下检查：
- 用 rpm -qip 查看包信息
- 用 rpm -qlp 查看包内文件列表
- 安装测试：sudo yum localinstall 包文件
- 卸载测试：sudo yum remove greeter
方案二：便携运行包配置
如果你的交付场景是给客户或离线环境使用，便携运行包会更灵活。
依赖收集脚本 pack.sh
这个脚本的核心工作是找出可执行文件所依赖的所有共享库，并复制到发布目录：
exe="greeter"
des="./release"
deplist=$(ldd "$exe" | awk '{if (match($3,"/")) printf("%s ",$3)}')
mkdir -p "$des" && cp $deplist "$des"
启动脚本 runner.sh
启动脚本负责设置库搜索路径并启动程序：
#!/bin/sh
appname=$(basename "$0" .sh)
dirname=$(dirname "$0")
[ "${dirname%/}" != "/" ] && dirname=$PWD/$dirname
export LD_LIBRARY_PATH=$dirname:$LD_LIBRARY_PATH
exec "$dirname/$appname" "$@"
这里有个细节：最好让runner.sh与可执行文件同名，或者调整脚本内部的appname变量。
目录结构与打包
将可执行文件、依赖库、配置文件、文档都放入同一个目录（比如 release/）。交付前一定要本地验证一下：直接执行 ./runner.sh 看看能否正常运行。跨机器部署前，确认架构一致、依赖完备、资源文件齐全。
方案三：库产物打包与链接配置
当你的项目需要以SDK形式提供给第三方开发者时，打包成库文件是必然选择。
静态库 .a
生成静态库很简单：
gcc -c add.c sub.c
ar -rc libmylib.a add.o sub.o
使用静态库时，链接阶段会将库代码直接并入可执行文件：
gcc main.c -I./include -L./lib -lmylib
共享库 .so
生成共享库需要编译位置无关的代码：
gcc -fPIC -c add.c sub.c
gcc -shared -o libmylib.so add.o sub.o
使用共享库时，编译命令与静态库类似，但运行期必须确保动态库可以被加载。常见的方式包括：将库文件放在系统库目录、设置LD_LIBRARY_PATH、或者通过ldconfig配置。
链接选项要点
- -I 指定头文件搜索路径
- -L 指定库文件搜索路径
- -l 指定库名，注意要去掉lib前缀和.a/.so后缀
运行时的库解析问题容易踩坑：如果动态库路径不在系统默认搜索路径中，一定要通过LD_LIBRARY_PATH或系统库目录/缓存机制来确保程序能找到库文件。
实践建议
最后说几条实际项目中积累下来的经验。
构建效率方面：用CMake管理工程几乎是标配，配合并行构建（make -jN 或 ninja -jN）能显著缩短编译时间。如果项目规模较大，还可以考虑预编译头（PCH）来进一步提升速度。多编译器共存时，别忘了用 -DCMAKE_CXX_COMPILER 指定编译器路径，避免误用了旧版工具链。
交付策略方面：面向内部分发时，RPM包是首选，因为依赖清晰、可以回滚。面向客户或离线环境时，便携运行包更合适，部署简单、路径可控。对外提供SDK时，输出 .a/.so 加上头文件，再附一份链接示例，这几乎是行业标准做法。
