-common -prefix=… (non-root local install) fails: yosys readline dep does a root-only apt-get

[mguthaus]

Summary

The -common dependency phase is intended to run without root and install into a user-specified prefix (-prefix=DIR / -local). But it tries to apt-get install libreadline-dev for the yosys build, which requires root, so a non-privileged local install fails.

Steps to reproduce

On a fresh master checkout:

source dev_env.sh
sudo ./etc/DependencyInstaller.sh -base
./etc/DependencyInstaller.sh -common -prefix="./dependencies"
./build_openroad.sh

During the third step (-common), it fails:

[INFO] Installing libreadline-dev for yosys... ✖
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
[ERROR] Failed to execute: apt-get -y install --no-install-recommends libreadline-dev

Environment

• OS: Ubuntu 24.04.4 LTS
• ORFS: master (7b05472e7)
• OpenROAD submodule pin: 04cbde6e14

Root cause

In tools/OpenROAD/etc/DependencyInstaller.sh, readline was moved out of the -base package lists and into a build-time step that runs during -common:

# OpenROAD itself uses vendored linenoise, so readline is no longer in the
# base package lists. Yosys still requires it at compile time, so install it
# here right before the yosys build.
_install_yosys_dependencies() {
    if _command_exists "apt-get"; then
        export DEBIAN_FRONTEND="noninteractive"
        _execute "Installing libreadline-dev for yosys..." \
            apt-get -y install --no-install-recommends libreadline-dev
    ...

Call chain: -common → (-eqy) _install_equivalence_deps → _install_yosys → _install_yosys_dependencies → apt-get install libreadline-dev.

libreadline-dev no longer appears in any -base/-all apt list, so it is only installed from this path. This puts a privileged, system-wide apt-get inside the unprivileged -common phase, which contradicts the -prefix/-local non-root use case (and setup.sh, which deliberately runs -common as $SUDO_USER).

What's the intended fix for a non-root "local" -common build?

A few options — would appreciate guidance on the preferred one:

1. Move readline back into -base (the privileged phase), where the other system -dev packages live. -common then assumes it's already present. Simplest and matches the original layout.
2. Skip the apt-get in -common when unprivileged / already present, e.g. guard _install_yosys_dependencies with [[ -f /usr/include/readline/readline.h ]] || [[ "$(id -u)" -ne 0 ]] && return 0, and document that readline must be installed via -base/system beforehand.
3. Build readline into the prefix like the other -common deps (heaviest; probably overkill for a system lib).

More broadly: is a fully non-root -common -prefix=… (tools into a user tree, system -dev libs via a one-time sudo -base) a supported workflow? It seems like a common thing to want, so it's surprising it currently breaks.

[maliberty]

I recommend you use setup.sh of calling the scripts directly.

[mguthaus]

How can I use setup.sh and install dependencies (-common) locally (not in /usr/local)?

I have students that use a shared machine and do not have root. I generally run the install with -base and they might need to use updated dependencies with -common (without root).

[mguthaus]

setup.sh has this same failure because it also runs the -common option without root:

git clone git@github.com:The-OpenROAD-Project/OpenROAD-flow-scripts.git myorfs
cd myorfs
sudo ./setup.sh

produces:

[INFO] Installing libreadline-dev for yosys... ✖
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
[ERROR] Failed to execute: apt-get -y install --no-install-recommends libreadline-dev

[maliberty]

I don't know that we have a pure rootless install. You might want to use bazel or docker.

@vvbandeira @sombraSoft any ideas?

[maliberty]

@oharboe will be glad to sell you on the wonders of https://github.com/The-OpenROAD-Project/bazel-orfs

[mguthaus]

I don't mean completely rootless. It's fine that the apt dependencies require root. The -base has always required root but -common has not. This is a recent change and a simple dependency fix to correct -- we just need the yosys apr-get calls to be removed from -common and put back in -base where they used to be.

[mguthaus]

Also, the root-based install is broken as well due to the issue. See my second comment.

[oharboe]

@mguthaus I feel your pain. We gave up on docker and dependencyinstaller this spring and haven't looked back.

bazel-orfs requires no install other than bazelisk, but it does compile everything from scratch. I think for a student use-case binary releases would be enormously helpful as I can imagine for a lab-use case they need to hit the ground running. I have a plan for binary release bazel native toolchains in bazel-orfs, but it depends on the openroad project hosting the binaries and nobody is tugging on this rope.

For our use-case we wouldn't use these toolchain binaries as historically we always have some patches in flight and bazel provides a way to separate concerns: we run with a patch to address the urgency and we file pull requests only when the churn of the fixes has died down and then the upstreaming PRs can be dealt with at the maintainers pace and priorities.

If someone solves the hosting of the binary toolchains, then claude can do the rest of the work in bazel-orfs for binary release openroad/yosys/abc toolchains.

A "bazel toolchain" is a very specific bazel idiomatic concept that solves a bunch of issues using the same paradigm that is used for C++ bazel toolchains with binary releases.

[mguthaus]

@maliberty The reason that the Docker image and the other testing still works is that these don’t execute setup.sh with sudo, but instead execute it as root. However, when you follow the install instructions, this call in the setup.sh script:

sudo -u $SUDO_USER "$DIR/etc/DependencyInstaller.sh" -common -prefix="$DIR/dependencies"

is executed as the user which in turn calls apt-get for yosys and fails.

So, the current “user” installation instructions don’t work at all as given here:
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/docs/user/BuildLocally.md#clone-and-install-dependencies

Should we change those instructions (to only run setup.sh as root not with sudo) or remove the apt-get call in the -common dependency installer for Yosys?

[mguthaus]

Filed a fix on OpenROAD: The-OpenROAD-Project/OpenROAD#10569. It implements option 1 from the original report — libreadline-dev (and the equivalents for RHEL/openSUSE/Darwin) moves out of the per-build _install_yosys_dependencies() helper invoked during -common, back into the per-platform _install_*_packages functions that the -base phase runs. _install_yosys_dependencies() itself is deleted; the rest of _install_yosys() is unchanged. With that in, the standard sudo ./setup.sh install path (and ./etc/DependencyInstaller.sh -common -prefix=… as a non-root user with -base previously installed) both work again without changing the -base / -common privilege contract.