Building ORFS locally on Ubuntu 24.04 - boost version issue?

[chrisgelinek-rl]

After running

cd OpenROAD-flow-scripts/
sudo etc/DependencyInstaller.sh -all
sudo tools/OpenROAD/etc/DependencyInstaller.sh -all

# there seem to be a couple of libraries missing, install them manually
sudo apt install libspdlog-dev  libeigen3-dev  liblemon-dev

I'm trying to build ORFS locally with a custom install-path, as so:

./build_openroad.sh --no_init  --local  --install-path "${INSTALL_PATH}"

but that leads to the following error:

gmake[1]: *** [CMakeFiles/Makefile2:93: CMakeFiles/foo.dir/all] Error 2
gmake[1]: Leaving directory '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/src/sta/CMakeFiles/_CMakeLTOTest-CXX/bin'
gmake: *** [Makefile:94: all] Error 2


-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so
-- TCL header: /usr/include/tcl/tcl.h
-- std::format: available
-- CUDD library: /usr/local/lib/libcudd.a
-- CUDD header: /usr/local/include/cudd.h
-- Found SWIG: /usr/local/bin/swig (found suitable version "4.3.0", minimum required is "3.0")
-- SWIG version: 4.3.0
-- STA library: /radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/libOpenSTA.a
-- STA executable: /radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/sta
-- Found OR-Tools: /opt/or-tools/lib/cmake/ortools (version: 9.14.6206)
-- TCL library: /usr/lib/x86_64-linux-gnu/libtcl.so
-- TCL header: /usr/include/tcl/tcl.h
-- GUI is enabled
-- Could NOT find VTune (missing: VTune_LIBRARIES VTune_INCLUDE_DIRS) 
CMake Error at /opt/or-tools/lib/cmake/Boost-1.87.0/BoostConfig.cmake:67 (find_package):
  Could not find a configuration file for package "boost_iostreams" that
  exactly matches requested version "1.87.0".

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/boost_iostreams-1.83.0/boost_iostreams-config.cmake, version: 1.83.0
    /lib/x86_64-linux-gnu/cmake/boost_iostreams-1.83.0/boost_iostreams-config.cmake, version: 1.83.0

Call Stack (most recent call first):
  /opt/or-tools/lib/cmake/Boost-1.87.0/BoostConfig.cmake:128 (boostcfg_find_component)
  src/utl/CMakeLists.txt:6 (find_package)


-- Configuring incomplete, errors occurred!

Does anyone have a suggestion what to do next?

[yudin-s]

Your log is not asking for "any Boost iostreams"; it is asking for the Boost version exported by the OR-Tools package under /opt/or-tools.

This line is the clue:

CMake Error at /opt/or-tools/lib/cmake/Boost-1.87.0/BoostConfig.cmake

That package exports a Boost 1.87 config, so CMake then looks for boost_iostreams at exactly 1.87.0. Ubuntu 24.04 provides Boost 1.83, so the component config under /usr/lib/.../boost_iostreams-1.83.0 is rejected.

I would avoid mixing the /opt/or-tools dependency set with Ubuntu 24.04 packages. The OpenROAD build docs also warn that the dependency installer defaults to /usr/local unless you use the local/prefix flow, so stale global installs can easily leak into later builds.

For a clean ORFS build, I would try the flow wrapper first:

# from a clean OpenROAD-flow-scripts checkout
./setup.sh

or, if you need the manual dependency path, install dependencies with a consistent local prefix instead of using whatever is already in /opt and /usr/local.

For diagnosis, check which OR-Tools CMake package is being picked up:

cmake --debug-find-pkg=ortools ...

or temporarily move /opt/or-tools out of CMAKE_PREFIX_PATH / PATH and rebuild from a clean build directory. If the error disappears, the fix is to use an OR-Tools build that brings matching Boost components, or rebuild/install OR-Tools and Boost as one consistent dependency set.

So I would not manually install only libboost-iostreams-dev here; that gives you 1.83 and still will not satisfy an exact 1.87 request from /opt/or-tools.

If removing /opt/or-tools from the search path changes the failure, you have confirmed a mixed OR-Tools/Boost dependency set. If that is the cause, marking this answered would help other Ubuntu 24.04 local builders.

[maliberty]

I suggest you use setup.sh rather than call the dependency installer directly.

[chrisgelinek-rl]

Thanks for looking into this.

@yudin-s I haven't manually installed libboost-iostreams-dev to my knowledge... and I'm not sure about the "manual dependency path" you mentioned?

I started from a clean Ubuntu 24.04 installation, so any /opt/or-tools or extra /usr/local files would've come from the DependencyInstaller.sh scripts... instead I probably should've run ./setup.sh.

Since I don't know enough about cmake and how to use it to debug the CMAKE_PREFIX_PATH the build uses, I simply removed the /opt contents and tried to start afresh:

sudo rm -rf /opt/*
git reset --hard HEAD
git clean -fd
sudo ./setup.sh
./build_openroad.sh --no_init  --local  --install-path "${INSTALL_PATH}"

Here are some excerpts from the build output, hopefully that gives a clue as to where the problem may be:

Running pre-compilation system checks...
[OK] Found cmake
[OK] Found bison
[OK] Found flex
[OK] Found swig
[OK] Found gcc
[OK] Found g++
All pre-compilation checks passed! Proceeding...

[INFO] Using 24 threads.
-- OpenROAD version: 26Q2-1994-g065077a742
-- System name: Linux
-- Compiler: GNU 15.2.0
-- Build type: RELEASE
-- Install prefix: /radstd/tools/openroad/build-2026-06-15/ubuntu24.04/OpenROAD
-- C++ Standard: 20
-- C++ Standard Required: ON
-- C++ Extensions: OFF
-- LTO/IPO is not supported: Change Dir: '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/bin'

[...]

Scanning dependencies of target foo
gmake[2]: Leaving directory '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/bin'
/usr/bin/gmake  -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/build
gmake[2]: Entering directory '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/bin'
[ 25%] Building CXX object CMakeFiles/foo.dir/foo.cpp.o
/usr/bin/g++   -flto=auto -fno-fat-lto-objects -o CMakeFiles/foo.dir/foo.cpp.o -c /radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/src/foo.cpp
[ 50%] Linking CXX static library libfoo.a
/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/dependencies/bin/cmake -P CMakeFiles/foo.dir/cmake_clean_target.cmake
/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/dependencies/bin/cmake -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1
"/usr/bin/gcc-ar-15" qc libfoo.a CMakeFiles/foo.dir/foo.cpp.o
Error running link command: no such file or directorygmake[2]: *** [CMakeFiles/foo.dir/build.make:103: libfoo.a] Error 2
gmake[2]: Leaving directory '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/bin'
gmake[1]: *** [CMakeFiles/Makefile2:93: CMakeFiles/foo.dir/all] Error 2
gmake[1]: Leaving directory '/radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/tools/OpenROAD/build/CMakeFiles/_CMakeLTOTest-CXX/bin'
gmake: *** [Makefile:94: all] Error 2


[...]

CMake Warning at src/mpl/test/cpp/CMakeLists.txt:19 (add_executable):
  Cannot generate a safe runtime search path for target
  TestBlockMacroChannels because files in some directories may conflict with
  libraries in implicit directories:

    runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /radstd/tools/openroad/build-2026-06-15/OpenROAD-flow-scripts/dependencies/or-tools/lib

  Some of these libraries may not be found correctly.


CMake Error at src/odb/test/cpp/CMakeLists.txt:45 (target_link_libraries):
  Target "OdbGTests" links to:

    GTest::gmock

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

[...]

-- Generating done (12.7s)
CMake Generate step failed.  Build files cannot be regenerated correctly.

[chrisgelinek-rl]

OK, I went ahead and re-installed the OS from scratch, to ensure there's nothing leaking into the build from previous attempts. The errors look identical to the ones shown in my previous post, full setup.sh and build log attached:

setup.sh.log

radlogic_build.log

What can I try next?

[chrisgelinek-rl]

Searching a little seems to suggest that the build scripts expect gcc-15, but installed is gcc-13:

$ gcc --version
gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0

...which raises the question: Who's right? Should I try to install gcc-15 on the machine, or should the build scripts use the one provide by the OS package manager?

[yudin-s]

I would avoid installing GCC 15 right now. The failure mode now appears to be a toolchain consistency issue: CMake selected GCC 15 (GNU 15.2.0), but the expected archiver wrapper /usr/bin/gcc-ar-15 is missing. That points to a compiler/AR mismatch in the environment, not back to the original Boost/OR-Tools conflict.

The confusing part is that your shell gcc --version shows Ubuntu's GCC 13, while the OpenROAD configure step says:

Compiler: GNU 15.2.0
"/usr/bin/gcc-ar-15" qc libfoo.a ...

So I would first find where that compiler choice is coming from:

which gcc g++ c++ cmake
which gcc-ar gcc-ar-13 gcc-ar-14 gcc-ar-15 || true
printenv | grep -E '^(CC|CXX|AR|CMAKE_PREFIX_PATH|PATH)='
rg -n 'CMAKE_(C|CXX)_COMPILER|CMAKE_AR|gcc-ar' tools/OpenROAD/build/CMakeCache.txt

If CMakeCache.txt points at GCC 15 or /usr/bin/gcc-ar-15, remove the build cache before retrying:

rm -rf tools/OpenROAD/build

Then either build with a verified system compiler set:

CC=/usr/bin/gcc CXX=/usr/bin/g++ AR=/usr/bin/gcc-ar ./build_openroad.sh --no_init --local --install-path "${INSTALL_PATH}"

or, if the maintainers confirm current ORFS is meant to use GCC 15, install/provide the whole matching GCC 15 toolchain, including gcc-ar-15, not just g++-15.

The current Ubuntu 24.04 dependency installer path I see installs libstdc++-14-dev, not GCC 15 itself, so I would not treat "install gcc-15 manually" as the first-line fix unless a maintainer confirms that is now expected. GTest::gmock is likely a secondary symptom from the same broken configure/dependency state; it should be easier to isolate after CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, and CMAKE_AR are consistent in a fresh cache.