前情提要系统Debian13在一台非常老的64位机器除了系统什么包也没有装一些报错就要自己手动装。尝试手动配置一个一个依赖编译失败fmt 版本与 spdlog 适配上最后用官方脚本配置了OpenRoad现在尝试使用OpenROAD-flow-scripts脚本配置记录一下出错环节各种依赖冲突git clone --recursive \ https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git cd OpenROAD-flow-scripts sudo ./setup.sh ./build_openroad.sh --local首先遇到问题是无法找到or-toolsGpt说OpenROAD 上确实有人遇到了几乎完全一样的问题2026 年 7 月的一个 issue 里DependencyInstaller.sh 把 OR-Tools 装到$HOME/prefix/or-tools/但用户只把$HOME/prefix放进CMAKE_PREFIX_PATH于是就得到和你几乎一模一样find_package(ortools) 错误。https://github.com/The-OpenROAD-Project/OpenROAD/issues/11033CMake Error at src/gpl/CMakeLists.txt:12 (find_package): By not providing Findortools.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by ortools, but CMake did not find one.先查 OR-Tools 到底有没有装find /usr/local /opt $HOME \ -type f \ \( -name ortoolsConfig.cmake -o -name ortools-config.cmake \) \ 2/dev/null # 我的输出 /home/x/.local/or-tools/lib/cmake/ortools/ortoolsConfig.cmake把 OR-Tools 的 prefix 加进去echo看有没有加进去在重新开始跑sh脚本export CMAKE_PREFIX_PATH/home/x/.local/or-tools:/home/x/.local:$CMAKE_PREFIX_PATH echo $CMAKE_PREFIX_PATH ./build_openroad.sh --localAbseil (absl) 版本和当前链接器实际拿到的 Abseil 不匹配8416:/usr/bin/ld: /home/X/.local/or-tools/lib/libortools.so.9.14.6206: undefined reference to symbol _ ZN4absl12lts_2025051216numbers_ internal15FastIntToBufferElPc 8418:collect2: error: ld returned 1 exit statusAbseil 的路径为/usr/local/lib/cmake/absl应该和 or-tools配套使用find/home/xin/.local/or-tools\-typef\\(-nameabslConfig.cmake-o-nameabslConfigVersion.cmake\)我预计你很可能会看到/home/x/.local/or-tools/lib/cmake/absl/abslConfig.cmake /home/x/.local/or-tools/lib/cmake/absl/abslConfigVersion.cmake如果有那这套才应该和你的 OR-Tools 一起使用。如果 OR-Tools 目录里带有 Abseil就优先用它因为预编译 OR-Tools 是和那套 Abseil 配套的混用另一套 Abseil 可能导致链接或运行时错误重新配置只删 CMakeCache.txt不要删整个 build 目录。 这样之前编出来的大部分 .o 文件还在cd /home/x/OpenROAD-flow-scripts rm -f tools/OpenROAD/build/CMakeCache.txt unset absl_DIR unset ortools_DIR unset ABSL_ROOT unset ortools_ROOT unset CMAKE_PREFIX_PATH export CMAKE_PREFIX_PATH/home/x/.local/or-tools:/home/x/.local ./build_openroad.sh --local -t 4你的目录实际上是/home/xin/.local ├── ... └── or-tools ├── lib/libortools.so └── lib/cmake/ ├── ortools/ └── absl/所以 OR-Tools 的真正 prefix 是/home/x/.local/or-tools不是/home/x/.local而 OpenROAD 官方安装逻辑现在也是刻意把 OR-Tools 当成一个独立 prefix并优先寻找它里面 bundled 的 Abseil就是为了避免“两套 Abseil 同时存在”造成链接或运行时问题。Boost 的版本冲突The following configuration files were considered but not accepted: /home/xin/.local/lib/cmake/boost_iostreams-1.89.0/ boost_iostreams-config.cmake, version: 1.89.0 /usr/lib/x86_64-linux-gnu/cmake/boost_iostreams-1.83.0/ boost_iostreams-config.cmake, version: 1.83.0GPT解释OpenROAD 当前自己的依赖版本是 Boost 1.89而 OR-Tools 9.14.6206 的预编译包里带了一个 Boost 1.87 的 CMake 配置。OpenROAD 的 src/utl/CMakeLists.txt 会找 Boost iostreams现在 CMake 先撞到了 OR-Tools 目录里的 Boost-1.87.0/BoostConfig.cmake于是它要求 exactly 1.87.0但你真正有的是 ~/.local 的 1.89 和系统的 1.83所以都被拒绝了。也就是说现在是~/.local/or-tools ├── OR-Tools 9.14 ✅ ├── Abseil 20250512 ✅ 应该给 OR-Tools 用 └── BoostConfig 1.87 ⚠️ 不应该让 OpenROAD 的 find_package(Boost) 捡到 ~/.local └── Boost 1.89 ✅ OpenROAD 当前需要的版本 Boost → ~/.local (1.89) ORTools → ~/.local/or-tools (9.14) Abseil → ~/.local/or-tools (20250512)不要把整个 or-tools 目录作为全局 CMake 搜索前缀。最干净的方式是创建 ORFS 本身支持的依赖配置文件。build_openroad.sh 会自动寻找根目录下的 openroad_deps_prefixes.txt 并传给 OpenROAD 的 Build.sh。https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/build_openroad.sh。所以你现在不用安装 Boost 1.87更不要卸载 Boost 1.89。1.89 才是当前 OpenROAD installer 指定的版本。问题只是之前全局的 CMAKE_PREFIX_PATH 让 CMake误把 OR-Tools 内部那个 1.87 配置当成了 OpenROAD 自己的 Boost。cd /home/x/OpenROAD-flow-scripts cat openroad_deps_prefixes.txt EOF -DBoost_ROOT/home/x/.local -DBoost_DIR/home/x/.local/lib/cmake/Boost-1.89.0 -Dboost_iostreams_DIR/home/x/.local/lib/cmake/boost_iostreams-1.89.0 -Dortools_ROOT/home/x/.local/or-tools -Dortools_DIR/home/x/.local/or-tools/lib/cmake/ortools -DABSL_ROOT/home/x/.local/or-tools -Dabsl_DIR/home/x/.local/or-tools/lib/cmake/absl EOF rm -f tools/OpenROAD/build/CMakeCache.txt ./build_openroad.sh --local -t 4zlib报错Checking for module zlib -- Found zlib, version 9.9.3963 CMake Error in /home/x/OpenROAD-flow-scripts/tools/yosys/ build/CMakeFiles/CMakeScratch/TryCompile-DQ7uVh/CMakeLists.txt: Imported target PkgConfig::zlib includes non-existent path includeGPT解释CMake 通过 pkg-config 找到了一个叫 zlib 的配置但这个配置明显是错的/被污染了。正常 zlib 版本应该类似 1.3.1。.9.9.3963 是 OR-Tools 的版本号。 OR-Tools 自己依赖的 zlib 也是 1.x 系列当前 OR-Tools 源码使用的是 zlib 1.3.1。“include” 说明它读到的 zlib.pc 里include 路径也坏了——正常应该类似/usr/include。查它到底找到了哪个 zlib 最后那个 cat 很重要。我怀疑一打开就会看到类似Version: 9.9.3963 includedirinclude如果真是这样我们只需要把错误的 pkg-config 搜索路径/旧 zlib.pc 隔离掉不用重新安装整个 OpenROAD。pkg-config --modversion zlib pkg-config --variablepcfiledir zlib pkg-config --variableincludedir zlib echo $PKG_CONFIG_PATH find /home/xin/.local /usr/local /usr \ -name zlib.pc 2/dev/null cat $(pkg-config --variablepcfiledir zlib)/zlib.pc先验证 Debian 自带的 zlib 再直接看正确的 .pcdpkg -s zlib1g-dev | grep -E Status|Version cat /usr/lib/x86_64-linux-gnu/pkgconfig/zlib.pc 输出类似于 prefix/usr exec_prefix${prefix} libdir${prefix}/lib/x86_64-linux-gnu sharedlibdir${libdir} includedir${prefix}/include我的pkg-config几条输出为 总之变为 1.3.11.3.1 /usr/lib/x86_64-linux-gnu/pkgconfig /usr/include -lzunset PKG_CONFIG_PATH export PKG_CONFIG_PATH/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/share/pkgconfig:/home/x/.local/lib/pkgconfig pkg-config --modversion zlib pkg-config --variablepcfiledir zlib pkg-config --variableincludedir zlib pkg-config --cflags zlib pkg-config --libs zlib rm -f tools/yosys/build/CMakeCache.txt ./build_openroad.sh --local -t 4TBB报错社区有人提到过https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/issues/3968CMake Error at thirdparty/naja/CMakeLists.txt:121 (find_package): By not providing “FindTBB.cmake” in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by “TBB”, but CMake did not find one.这次是 TBBoneTBB开发包没有被 CMake 找到。它不是 OpenROAD 主体而是你现在已经走到后面的 kepler-formal → Naja 构建阶段当前 ORFS 的 build_openroad.sh 确实是在 OpenROAD、Yosys、yosys-slang 之后再编译 kepler-formal。你这里还有一个关键点你是普通 Debian不是 Ubuntu。当前 ORFS 的依赖脚本里libtbb-dev 确实已经列入 apt 安装清单但 OS 分支明确匹配的是 Ubuntu 和 Google 的 Debian GNU/Linux rodete不是通用 Debian。而且你这个报错非常巧ORFS 在 2026 年 3 月有人报过几乎一模一样的问题也是 yosys-slang 显示 [100%] 后进入 Compiling kepler-formal然后 thirdparty/naja/CMakeLists.txt 找不到 TBBConfig.cmake。这个 issue 后来通过 PR #3981 修了把 Kepler 所需依赖加入了正常安装流程。Debian 官方的 libtbb-dev 就是 oneTBB 的开发包。amd64 包会提供https://packages.debian.org/pl/sid/amd64/libtbb-dev/filelist/usr/lib/x86_64-linux-gnu/cmake/TBB/TBBConfig.cmake /usr/lib/x86_64-linux-gnu/cmake/TBB/TBBConfigVersion.cmake /usr/lib/x86_64-linux-gnu/libtbb.so先检查再安装依赖dpkg -s libtbb-dev 2/dev/null | grep -E Status|Version find /usr /usr/local $HOME/.local \ -type f -name TBBConfig.cmake 2/dev/null sudo apt update sudo apt install -y libtbb-dev ls /usr/lib/x86_64-linux-gnu/cmake/TBB/TBBConfig.cmake rm -f tools/kepler-formal/build/CMakeCache.txt ./build_openroad.sh --local -t 4Cap’n Proto 报错和上一个模块类似dpkg -s capnproto libcapnp-dev 2/dev/null | grep -E Package|Status|Version sudo apt update sudo apt install -y capnproto libcapnp-dev capnp --version find /usr -type f -name CapnProtoConfig.cmake 2/dev/null rm -f tools/kepler-formal/build/CMakeCache.txt ./build_openroad.sh --local -t 4最后进行验证有个小问题不是yosys -m slang -p slang_version因为-m slang意思是加载一个外部动态插件 slang.so 。关键是Yosys 0.67/0.68 这一代已经把 Slang frontend 集成到 Yosys 本体里了。 当前 Yosys 的 CMake 默认 YOSYS_WITHOUT_SLANGOFF也就是启用内置 Slang当前文档也已经把 read_slang、slang_version 列为 Yosys 自带命令source ./env.sh which openroad openroad -version which yosys yosys -p slang_version cd flow make make gui_finalYosys 是不是以内置 Slang 构建最新 ORFS 的 build_openroad.sh 现在直接用 CMake 编译、安装 Yosys然后就继续编 kepler-formal已经不像旧版脚本那样单独编译一个 yosys-slang 插件grep -E YOSYS_WITHOUT_SLANG|YOSYS_ENABLE_SLANG \ /home/x/OpenROAD-flow-scripts/tools/yosys/build/CMakeCache.txt YOSYS_WITHOUT_SLANG:BOOLOFF WITHOUT_SLANG OFF ↓ 没有禁用 Slang ↓ Slang 已编进 YosysKLayout 没装sudo apt update sudo apt install -y klayout command -v klayout klayout -v