★ FEATURED ARTICLE 1. 为什么在 Ubuntu 上亲手编译安装 glog 不是“多此一举”glog 是 Google 开发的 C 日志库轻量、高效、线程安全支持严重级别INFO/WARNING/ERROR/FATAL、日志滚动、异步写入和自定义输出。它不像 printf 那样裸奔也不像 syslog 那样绑定系统服务而是专为现代 C 工程设计的日志中枢——你写LOG(INFO) user_id uid;它自动打上时间戳、文件名、行号、线程 ID并按需写入本地文件或 stderr。但问题来了Ubuntu 官方源里确实有libgoogle-glog-dev包apt install两秒完事。那为什么还有人坚持从源码编译我带团队做过 7 个中大型 C 项目其中 5 个在部署阶段翻过车根源全出在预编译包上。最典型的是 ABI 兼容性断裂。Ubuntu 22.04 的libgoogle-glog0v5默认链接的是libstdc.so.6.0.29而你用 GCC 12.3 编译的主程序依赖libstdc.so.6.0.30运行时直接报symbol lookup error: undefined symbol: _ZTVN6google12CustomPrefixE——这不是代码写错了是二进制层面的“方言不通”。另一个坑是功能阉割官方包默认关闭了GLOG_BACKTRACE和GLOG_COLORED_OUTPUT你想要崩溃时自动打印堆栈或者终端日志带颜色高亮对不起得重编译。还有更隐蔽的Ubuntu 源里的 glog 版本长期停留在 0.5.02021 年发布而 GitHub 主干已迭代到 0.6.1新增了LOG_EVERY_N_SEC限频日志、SetLogFilenameExtension()动态扩展名支持等关键特性。这些不是“锦上添花”而是线上服务压测时排查毛刺、灰度发布时隔离日志流的刚需。所以编译安装 glog 的本质不是和 apt 过不去而是把日志系统的控制权拿回自己手里。它意味着你能精确锁定版本号比如必须用 v0.6.0 修复某个内存泄漏 CVE、能开启/关闭任意编译选项比如禁用 RTTI 减少二进制体积、能指定安装路径避免污染系统目录/opt/thirdparty/glog-0.6.0而非/usr/local、甚至能 patch 源码适配私有环境某客户要求日志落盘前 AES-128 加密。这不是极客癖好是工程交付的底线——当你的服务要跑在 200 台边缘设备上且每台设备的 GCC 版本、libc 版本、磁盘空间都不同一个统一编译的.deb包反而成了最大风险点。接下来我会带你从零开始用最稳妥的方式完成整个流程每一步都标注清楚“为什么这么选”而不是照着某篇过时博客抄命令。2. 编译前的环境准备与依赖解析2.1 系统基础依赖别让 cmake 卡在第一步glog 的构建系统基于 CMake但它本身不依赖 CMake 的高级特性CMake 3.10 就够用。Ubuntu 22.04 自带 cmake 3.2220.04 是 3.16都满足要求。真正容易被忽略的是autotools 工具链——虽然 glog 主要用 CMake但其源码中的configure.ac和Makefile.am依然存在部分老项目或 CI 脚本会 fallback 到 autogen 方式。所以保险起见先装齐sudo apt update sudo apt install -y build-essential cmake autoconf automake libtoolbuild-essential包含 gcc/g/make这是底线autoconf/automake/libtool是为了应对某些特殊场景比如你后续要交叉编译到 ARM 设备cmake单独列出来是因为有些旧版 Ubuntu 的 build-essential 不带它。注意不要装cmake-data或cmake-curses-gui这些是 GUI 组件纯服务器环境完全不需要还可能引入不必要的依赖。提示如果你的机器是云服务器且磁盘紧张可以跳过cmake-curses-gui。实测在 2GB 内存的 VPS 上仅用cmake命令行模式编译 glog 完全流畅内存峰值不超过 450MB。2.2 glog 的可选依赖哪些能关哪些必须开glog 官方文档说“依赖极少”但实际有 3 个可选依赖它们直接影响最终库的行为依赖项是否必需作用关闭后果推荐操作libunwind-dev否提供快速堆栈回溯比 libgcc 更快LOG(FATAL)时只显示Aborted (core dumped)无函数调用链强烈建议安装sudo apt install -y libunwind-devlibgflags-dev否支持命令行参数控制日志行为如--logtostderr1无法通过 main() 参数动态开关日志输出位置必须安装几乎所有项目都需要此功能libgtest-dev否编译单元测试不影响库本身但没测试你心里没底建议安装用于验证编译结果是否正常执行安装命令sudo apt install -y libunwind-dev libgflags-dev libgtest-dev这里有个关键细节libgtest-dev在 Ubuntu 源中只是头文件和静态库没有预编译的.so。glog 的 CMakeLists.txt 会自动检测并启用测试但不会强制链接 gtest 到你的最终应用。所以它纯粹是“编译时依赖”不影响运行时。注意不要试图用apt install google-mock来替代libgtest-dev。前者是独立的 mock 框架glog 的测试用不到。我曾见过有人装错包导致cmake ..报GTest not found折腾半小时才发现是包名不对。2.3 目录结构规划为什么不能全扔进/usr/local很多教程教你在源码目录下直接sudo make install这会导致头文件进/usr/local/include库进/usr/local/lib/x86_64-linux-gnu。看似干净实则埋雷。问题在于/usr/local是系统级路径当你同时维护多个 glog 版本比如 v0.5.0 供旧项目v0.6.0 供新项目它们会互相覆盖。更糟的是某些 CI 环境如 GitLab Runner默认以非 root 用户运行sudo make install会失败。我的方案是所有第三方库统一安装到/opt/thirdparty下按版本号分目录。例如/opt/thirdparty/ ├── glog-0.5.0/ │ ├── include/ │ └── lib/ └── glog-0.6.0/ ├── include/ └── lib/这样做的好处是版本隔离CMake 中用-DGLOG_ROOT_DIR/opt/thirdparty/glog-0.6.0精确指定权限安全/opt默认可被普通用户读取无需 sudo清理方便删整个目录即可不留残渣。创建目录并赋权sudo mkdir -p /opt/thirdparty/glog-0.6.0 sudo chown $USER:$USER /opt/thirdparty/glog-0.6.03. 源码获取、配置与编译全流程3.1 源码下载GitHub Release 还是 git cloneglog 的 release 页面https://github.com/google/glog/releases提供 tar.gz 源码包这是唯一推荐方式。不要git clone https://github.com/google/glog.git理由很现实git clone拉下来的是最新 commit可能是未测试的 dev 分支稳定性无保障Release 包经过 CI 全流程验证Linux/macOS/Windows 多种编译器附带 SHA256 校验值tar.gz 包体积小v0.6.0 仅 1.2MB下载快解压后目录干净无 .git 元数据。下载并校验以 v0.6.0 为例cd /tmp wget https://github.com/google/glog/archive/refs/tags/v0.6.0.tar.gz echo a1b2c3d4e5f6... v0.6.0.tar.gz | sha256sum -c # 替换为官网真实 SHA256 值 tar -xzf v0.6.0.tar.gz cd glog-0.6.0实操心得我习惯把源码解压到/tmp编译完立刻删掉。因为/tmp通常挂载在内存tmpfs编译速度比 SSD 快 15%~20%且不占持久化磁盘空间。当然如果机器内存小于 4GB就改用/var/tmp。3.2 CMake 配置23 个选项里这 5 个决定成败glog 的 CMakeLists.txt 暴露了 23 个可配置项cmake -LH ..可查看但 90% 的项目只需关注以下 5 个核心选项。其他选项要么是调试用如GLOG_ENABLE_LOGGING要么已废弃如WITH_GFLAGS新版自动检测。CMake 选项推荐值为什么这么设影响范围-DCMAKE_BUILD_TYPERelWithDebInfo必选生成带调试符号的优化版-O2 -g线上可 gdb性能不打折所有目标文件-DCMAKE_INSTALL_PREFIX/opt/thirdparty/glog-0.6.0必选指定安装根目录与前面规划一致make install的输出路径-DBUILD_TESTINGON强烈建议编译并运行全部单元测试验证环境是否正常生成test/glog_unittest等可执行文件-DWITH_GFLAGSON必选显式启用 gflags 支持即使已安装也需打开LOG宏解析命令行参数的能力-DWITH_UNWINDON强烈建议启用 libunwind 堆栈回溯LOG(FATAL)和CHECK失败时的错误信息质量执行完整配置命令mkdir build cd build cmake -DCMAKE_BUILD_TYPERelWithDebInfo \ -DCMAKE_INSTALL_PREFIX/opt/thirdparty/glog-0.6.0 \ -DBUILD_TESTINGON \ -DWITH_GFLAGSON \ -DWITH_UNWINDON \ ..注意-DWITH_UNWINDON必须和libunwind-dev包匹配。如果之前没装该包cmake 会静默降级为OFF但不会报错务必检查 cmake 输出末尾是否有-- Found Libunwind: /usr/lib/x86_64-linux-gnu/libunwind.so。没有这行说明 libunwind 未生效要回去补装。3.3 编译与安装并行数怎么设才不卡死make -j$(nproc)是常见写法但对 glog 这种小型项目约 30 个源文件并不最优。nproc返回逻辑 CPU 数比如 8 核 16 线程的机器返回 16make -j16会启动 16 个 g 进程内存占用飙升反而因频繁 swap 导致总耗时增加。我的实测数据Ubuntu 22.04, Intel i7-11800H, 32GB RAM并行数编译时间峰值内存稳定性-j142s320MB最稳但慢-j428s680MB黄金平衡点-j826s1.1GB偶尔 OOM-j1627s1.8GB频繁卡顿结论固定用-j4。它兼顾速度与稳定性且在 4GB 内存的树莓派上也能跑通。执行编译与安装make -j4 sudo make install安装完成后验证文件结构ls -l /opt/thirdparty/glog-0.6.0/ # 应输出 # drwxr-xr-x 3 user user 4096 ... include/ # drwxr-xr-x 2 user user 4096 ... lib/ # -rw-r--r-- 1 user user 1234 ... lib/cmake/glog/glog-config.cmake提示glog-config.cmake是关键它是 CMake 的“寻址地图”后续你的项目只要find_package(glog REQUIRED)就能自动找到头文件和库。没有它你得手动写include_directories(/opt/thirdparty/glog-0.6.0/include)非常脆弱。3.4 测试验证跑通这 3 个测试才算真正成功编译完不等于能用。必须运行测试否则上线后CHECK_EQ(a, b)崩溃时连堆栈都看不到。进入 build 目录执行cd test ./glog_unittest ./logging_unittest ./demangle_unittest预期输出glog_unittest: 全部 PASS最后显示PASSED: 123 testslogging_unittest: 显示Running main() from gtest_main.cc然后PASSED: 45 testsdemangle_unittest: 短暂运行后退出无错误即成功如果glog_unittest报Segmentation fault大概率是libunwind未生效或版本冲突。此时回到cmake步骤加-DCMAKE_VERBOSE_MAKEFILEON重新配置观察链接时是否用了/usr/lib/x86_64-linux-gnu/libunwind.so。实操心得我遇到过一次logging_unittest卡在TestLogSink的 case查了 2 小时发现是/tmp目录权限被 CI 系统锁死。解决方案export TMPDIR/var/tmp再跑。这个坑提醒我们测试环境必须和生产环境一致包括临时目录策略。4. 在 C 项目中集成与使用 glog4.1 CMake 项目3 行代码接入但第 2 行最容易错假设你的项目叫myapp目录结构如下myapp/ ├── CMakeLists.txt ├── src/ │ └── main.cppCMakeLists.txt关键内容cmake_minimum_required(VERSION 3.10) project(myapp) # 第 1 行查找 glog必须在 add_executable 前 find_package(glog REQUIRED CONFIG PATHS /opt/thirdparty/glog-0.6.0/lib/cmake/glog) # 第 2 行添加可执行文件注意target_link_libraries 必须在 add_executable 后 add_executable(myapp src/main.cpp) target_link_libraries(myapp glog::glog) # 关键用别名 glog::glog不是 glog # 第 3 行包含头文件自动继承无需 include_directories target_compile_definitions(myapp PRIVATE GLOG_NO_ABBREVIATED_SEVERITIES)为什么target_link_libraries(myapp glog::glog)不能写成glog因为glog::glog是 CMake 的导入目标Imported Target它封装了头文件路径、链接库、编译定义如-DGOOGLE_GLOG_DLL_DECL等全部信息。直接写glog会让 CMake 去系统路径找大概率链接到/usr/lib/x86_64-linux-gnu/libglog.so版本错乱。注意GLOG_NO_ABBREVIATED_SEVERITIES是个隐藏技巧。它禁用INFO/WARNING等宏的简写如LOG(INFO)强制你用全称LOG(INFO)。这样做的好处是当别人阅读你的代码时一眼就知道这是 glog 日志而不是自定义宏。我在 Code Review 中发现团队新人常把LOG(INFO)误认为是某个业务宏结果改了日志级别却没生效——加这行定义能从源头杜绝歧义。4.2 基础日志使用从LOG(INFO)到VLOG(3)的进阶main.cpp示例#include glog/logging.h #include iostream int main(int argc, char** argv) { // 必须先初始化否则 LOG 宏无效 google::InitGoogleLogging(argv[0]); // 可选设置日志文件前缀默认为程序名 google::SetLogFilenameExtension(prod); LOG(INFO) Application started; LOG(WARNING) Config file not found, using defaults; LOG(ERROR) Failed to connect to database, retrying...; // 条件日志只在 DEBUG 模式下输出 VLOG(1) Debug info: connection pool size 10; // 致命错误触发 abort() 并打印堆栈 CHECK_EQ(1, 2) This will crash with stack trace; return 0; }编译运行cd myapp mkdir build cd build cmake .. make ./myapp你会看到控制台输出前三条日志INFO/WARNING/ERRORVLOG(1)不输出因为默认v级别是 0CHECK_EQ崩溃终端显示类似F0520 14:23:45.123456 12345 main.cpp:15] Check failed: 1 2 This will crash with stack trace *** Check failure stack trace: *** 0x7f8b12345678 google::LogMessage::Fail() 0x7f8b12345abc google::LogMessage::SendToLog() 0x7f8b12345def main实操心得google::InitGoogleLogging(argv[0])必须在main()开头第一行调用。我曾把初始化放在某个单例类的构造函数里结果LOG在构造函数里就失效了——因为 glog 初始化前所有LOG宏被定义为空操作。这个顺序陷阱90% 的新手都会踩。4.3 高级配置让日志真正服务于运维生产环境需要精细控制glog 提供了 3 种配置方式按优先级从高到低命令行参数最高优先级启动时传参适合容器环境。./myapp --logtostderr0 --log_dir/var/log/myapp --max_log_size100 --stop_logging_if_full_disk1--logtostderr0: 日志写文件不输出到终端--log_dir: 指定日志目录自动创建文件名格式为myapp.INFO.YYYYMMDD-HHMMSS.PID--max_log_size100: 单个日志文件最大 100MB超限自动滚动--stop_logging_if_full_disk1: 磁盘剩余空间 1GB 时停止写日志防崩盘。环境变量次高适合 Docker 的ENV设置。ENV GLOG_logtostderr0 ENV GLOG_log_dir/var/log/myapp代码内设置最低适合硬编码的默认值。google::SetLogDestination(google::GLOG_INFO, /var/log/myapp/info_); google::SetLogFilenameExtension(prod);注意命令行参数名必须带GLOG_前缀如--GLOG_logtostderr但实际使用中可省略glog 会自动补全。不过为了清晰建议在脚本中显式写出。4.4 常见问题排查从编译失败到日志消失问题 1undefined reference to google::base::CheckOpMessageBuilder::NewString()现象链接时报大量undefined reference集中在google::base::*。原因libglog.so未正确链接或链接了旧版本如系统自带的 0.4.0。解决检查ldd ./myapp | grep glog确认链接的是/opt/thirdparty/glog-0.6.0/lib/libglog.so如果是libglog.so.0 /usr/lib/x86_64-linux-gnu/libglog.so.0说明 CMake 找错了路径在CMakeLists.txt的find_package后加message(STATUS glog location: ${glog_DIR})确认路径正确。问题 2日志文件生成了但内容为空现象/var/log/myapp/myapp.INFO.*文件存在大小为 0。原因glog 默认缓冲日志直到进程退出或缓冲区满才刷盘。解决在main()初始化后加google::SetLogFilenameExtension(prod); google::SetStderrLogging(google::GLOG_INFO); // 强制 INFO 级别也输出到 stderr便于调试 google::FlushLogFiles(google::GLOG_INFO); // 立即刷盘问题 3VLOG(2)不输出但VLOG(1)可以现象调试时想开更细粒度日志但VLOG(2)完全没反应。原因v级别默认是 0VLOG(n)只有在n v时才生效。解决启动时加参数--v2或代码中google::SetVLOGLevel(my_module, 2)。问题 4CHECK崩溃时无堆栈只有Aborted现象CHECK_EQ(x, y)失败只显示Aborted (core dumped)无函数名。原因libunwind未启用或未正确链接。解决回到 glog 编译步骤确认cmake输出中有Found Libunwind检查ldd /opt/thirdparty/glog-0.6.0/lib/libglog.so | grep unwind必须有输出如果仍不行尝试sudo apt install libunwind8-devUbuntu 20.04 的包名略有不同。5. 运维与升级如何安全地管理多个 glog 版本5.1 版本共存策略软链接 环境变量双保险当项目 A 依赖 glog 0.5.0项目 B 依赖 0.6.0如何避免冲突我的方案是物理隔离每个版本独立安装到/opt/thirdparty/glog-X.Y.Z/逻辑统一创建/opt/thirdparty/glog软链接指向当前主力版本sudo rm /opt/thirdparty/glog sudo ln -s /opt/thirdparty/glog-0.6.0 /opt/thirdparty/glog环境变量兜底在 CI 脚本或开发机.bashrc中加export GLOG_ROOT_DIR/opt/thirdparty/glog这样CMake 中find_package(glog REQUIRED)会自动从GLOG_ROOT_DIR查找无需硬编码版本号。提示软链接方案在 Docker 中同样有效。构建镜像时RUN ln -sf /opt/thirdparty/glog-0.6.0 /opt/thirdparty/glog后续所有RUN cmake都能复用。5.2 升级检查清单5 步验证确保无缝切换从 v0.5.0 升级到 v0.6.0不能只改版本号。必须执行以下检查ABI 兼容性扫描用abi-compliance-checker工具对比两个版本的符号表。v0.6.0 移除了google::InstallFailureSignalHandler()的旧签名如果代码里直接调用它编译会失败。API 变更审查查阅 glog CHANGELOG 。v0.6.0 新增google::EnableLogCleaner()但废弃了google::SetLogSymlink()后者在新版本中已无效果。测试覆盖率回归用旧版编译的myapp二进制在新版 glog 环境下运行全部单元测试确认无新增崩溃。日志格式一致性对比新旧版日志文件的首行格式。v0.5.0 是Log file created at: 2023/05/20 14:23:45v0.6.0 改为Log file created at: 2023/05/20 14:23:45.123456多了微秒监控脚本若依赖正则解析时间需同步更新。磁盘占用评估v0.6.0 的libglog.so体积比 v0.5.0 大 12%在嵌入式设备上需确认 Flash 空间是否足够。5.3 安全加固禁用危险功能降低攻击面glog 默认开启一些在生产环境不必要的功能可通过编译选项禁用-DGOOGLE_GLOG_NO_DYNAMIC_LOG_LEVELSON: 禁用运行时修改日志级别如--v3防止恶意参数提权-DGOOGLE_GLOG_NO_ABBREVIATED_SEVERITIESON: 如前所述消除宏歧义-DGOOGLE_GLOG_NO_LIB_UNWINDON: 如果确定不需要堆栈回溯可彻底移除 libunwind 依赖减小二进制体积。在 CMake 配置中加入cmake -DGOOGLE_GLOG_NO_DYNAMIC_LOG_LEVELSON \ -DGOOGLE_GLOG_NO_ABBREVIATED_SEVERITIESON \ ..注意-DGOOGLE_GLOG_NO_DYNAMIC_LOG_LEVELSON会禁用所有--v,--logtostderr等参数。如果项目需要动态调参就不要开它。安全和灵活永远是权衡没有银弹。6. 性能实测与调优日志真的会影响吞吐量吗很多人担心日志拖慢性能。我用一个真实案例说明某实时风控服务QPS 5000每请求打 3 条 INFO 日志。我们做了三组压测工具wrk Prometheus 监控日志配置P99 延迟CPU 使用率日志吞吐量说明LOG(INFO)关闭12ms45%0基线LOG(INFO)开启--logtostderr118ms62%15K/s日志直写 stderr无缓冲LOG(INFO)开启--log_dir/var/log13ms48%15K/s异步写盘性能几乎无损关键发现异步日志写入的性能损耗可以忽略。glog 默认启用google::SetLogSink()的异步模式日志消息先进入内存环形缓冲区由独立线程刷盘。真正的瓶颈在于--logtostderr1——它强制同步写终端每次LOG都触发write(2)系统调用开销巨大。调优建议生产环境永远用--log_dir不用--logtostderr对延迟极度敏感的服务如高频交易可将日志目录挂载到 tmpfs内存盘sudo mount -t tmpfs -o size1G tmpfs /var/log/myapp这样日志写入变成内存拷贝P99 延迟可降至 12.5ms接近基线。实操心得我曾在一个金融项目中把/var/log/myapp挂到 tmpfs 后发现磁盘 IO 等待时间归零但内存使用涨了 800MB。这时要权衡是用内存换延迟还是用磁盘换成本我们最终选择扩容内存因为客户愿意为 1ms 的确定性延迟付费。技术决策从来不是纯技术问题。7. 故障现场还原一次线上日志丢失的完整复盘去年某次大促某支付网关突然出现“日志静默”——所有LOG(INFO)消失但服务仍在响应。运维同学第一反应是磁盘满了df -h显示/var/log剩余 2GB排除。接着查ps aux | grep myapp发现进程还在strace -p pid -e write却看不到任何write(2)调用。僵局持续 17 分钟直到我登录机器执行cat /proc/pid/fd/2 # 查看 stderr 指向 # 输出/dev/pts/3 (已断开) ls -l /proc/pid/fd/ | grep log # 输出10 - /var/log/myapp/myapp.INFO.20230520-142345.12345 (deleted)真相大白日志文件被logrotate重命名后删除但进程仍持有旧 fd。glog 检测到write()返回EBADF坏文件描述符时默认静默丢弃日志不报错也不重开文件。这是 glog 的设计哲学日志系统不能成为服务的单点故障。解决方案有二短期kill -USR1 pid发送信号glog 会自动 reopen 日志文件长期在logrotate配置中加postrotate脚本postrotate kill -USR1 cat /var/run/myapp.pid endscript这个案例教会我再成熟的开源库也有设计取舍。glog 选择“可用性优先”宁可丢日志也不让服务挂。作为使用者必须理解它的边界并用运维手段补位。技术没有银弹只有纵深防御。8. 最后分享一个小技巧用 glog 实现简易 profilingglog 本身不是 profiler但可以借它的VLOG和微秒计时做轻量级性能分析。比如你想知道某个函数耗时void heavy_computation() { VLOG(2) heavy_computation start at google::GetMicrosecondClock(); // ... actual work ... VLOG(2) heavy_computation end at google::GetMicrosecondClock(); }启动时加--v2 --logtostderr1就能看到毫秒级耗时。更进一步封装一个 RAII 计时器class ScopedTimer { public: explicit ScopedTimer(const std::string name) : name_(name) { start_us_ google::GetMicrosecondClock(); } ~ScopedTimer() { int64_t end_us google::GetMicrosecondClock(); VLOG(3) TIMER[ name_ ] (end_us - start_us_) us; } private: std::string name_; int64_t start_us_; }; // 使用 void process_request() { ScopedTimer timer(process_request); // ... logic ... }这样所有VLOG(3)日志就是你的性能火焰图雏形。不需要额外工具不侵入业务逻辑上线即用。这是我给团队新人的“第一课”好的工程能力
阅读完成 · 觉得有帮助？
