-prefix builds aren't hermetic for Abseil: ABSL_ROOT (uppercase) ignored under CMP0144 OLD, so a system or-tools' Abseil wins at link

Thanks for the recent dependency-installer work — the self-contained -prefix build is exactly what I want for keeping several checkouts isolated. I hit a case where the isolation leaks for Abseil specifically, and I don't think there's an open issue tracking it, so here's a write-up.

The short version: a -prefix build correctly pins or-tools to the local copy, but not Abseil. If a system or-tools is also present with a different Abseil version, the build compiles against the local Abseil and links the system one. And the standard setup path puts you in exactly that two-Abseil state.

How you end up with two Abseils

This is the part that makes it more than a messy-machine problem. The OpenROAD-Flow-Scripts setup.sh runs the installer twice:

etc/DependencyInstaller.sh -base                              # as root, no -prefix
etc/DependencyInstaller.sh -common -prefix="$DIR/dependencies" # as user, with -prefix

Both reach DependencyInstaller.sh, where the or-tools install target depends on whether -prefix is set (DependencyInstaller.sh:1296):

if [[ -n "${PREFIX}" ]]; then
    OR_TOOLS_PATH="${PREFIX}/or-tools"
else
    OR_TOOLS_PATH="/opt/or-tools"
fi

So the -base phase drops the prebuilt or-tools binary archive into /opt/or-tools (it bundles Abseil 20250512), and the -prefix phase builds the newer required Abseil (currently 20260107) into the prefix. Two Abseil LTS versions on one machine, straight out of a stock setup. Building the -prefix checkout then fails linking the odb SWIG binaries (odb_py, odbtcl):

/usr/bin/ld: ../../db/libdb.a(dbDatabase.cpp.o): in function `absl::lts_20260107::MutexLock::MutexLock(...)':
.../dependencies/include/absl/synchronization/mutex.h:614: undefined reference to `absl::lts_20260107::Mutex::lock()'

odb compiled against the local headers (lts_20260107), but the link line pulls /opt/or-tools/lib/libabsl_synchronization.so.2505.0.0 (lts_20250512) — different inline namespace, so the symbols aren't there.

Why or-tools resolves locally but Abseil doesn't

The generated prefixes file pins or-tools with ortools_ROOT (lowercase), which CMP0074 NEW honors, so or-tools resolves locally. Abseil is pinned with -D ABSL_ROOT=… (uppercase, DependencyInstaller.sh:716). Uppercase <PACKAGENAME>_ROOT only takes effect under CMP0144 NEW, and CMakeLists.txt:27 forces CMP0144 OLD for CMake ≥ 3.27 (mine is 3.31.9). So the Abseil pin is silently dropped, find_package(absl) falls back to the default search, and /opt/or-tools wins. This looks like the same conflict the TODO: resolve absl/or-tools issue and switch to NEW comment just above it (CMakeLists.txt:26) and #9471 ("we'll sort this out later") are referring to.

Reinstalling the prefix doesn't help — the stale absl_DIR=/opt/or-tools/lib/cmake/absl is cached in the build dir's CMakeCache.txt, and CMake won't re-search a cached *_DIR.

Workaround

Pin absl_DIR to the local copy and rebuild —

-D absl_DIR=$PWD/dependencies/lib/cmake/absl

or edit that one line in CMakeCache.txt. Removing/renaming the stale /opt/or-tools also works, since it takes the older Abseil off the search path. Either way the link line then resolves dependencies/lib/libabsl_synchronization.a and it builds clean.

Suggested fix

Since CMP0074 NEW is already set, having the installer emit the lowercase -D absl_ROOT=<prefix> (or -D absl_DIR=<prefix>/lib/cmake/absl directly) takes effect regardless of the CMP0144 state — matching how ortools_ROOT already behaves, and without needing to flip CMP0144 back to NEW. Opened #10650 with this change.

Environment: CMake 3.31.9, GCC 13, Ubuntu 24.04. Line references are against current master.

Start with DependencyInstaller.sh at lines 716 and 1296, then inspect CMakeLists.txt lines 26-27 for the CMP0144 policy and the existing TODO. Reproduce the prefix build with both /opt/or-tools and the prefixed Abseil installed; done means the build resolves and links the prefixed Abseil without editing CMakeCache.txt, while checking the related follow-up issue #10650.