fix: unsetenv RUNFILES_* in tcl_library_init#10173
Merged
maliberty merged 2 commits intoThe-OpenROAD-Project:masterfrom Apr 18, 2026
Merged
fix: unsetenv RUNFILES_* in tcl_library_init#10173maliberty merged 2 commits intoThe-OpenROAD-Project:masterfrom
maliberty merged 2 commits intoThe-OpenROAD-Project:masterfrom
Conversation
When OpenROAD is invoked by a build system that previously ran another Bazel binary (e.g. a Python wrapper in a Bazel action), the inherited RUNFILES_DIR / RUNFILES_MANIFEST_FILE env vars point to the *other* binary's runfiles tree. Runfiles::Create() checks those env vars first, so it resolves paths in the wrong tree. Unsetenv the three RUNFILES_* variables before Runfiles::Create() so it falls back to the exe_path derived from /proc/self/exe. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Contributor
There was a problem hiding this comment.
Code Review
This pull request modifies bazel/tcl_library_init.cc to clear inherited Bazel environment variables before initializing the runfiles library, ensuring correct path resolution. A review comment points out that unsetenv is a POSIX-specific function that will cause build failures on Windows, and suggests wrapping the calls in a platform-specific guard.
maliberty
approved these changes
Apr 17, 2026
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
Collaborator
Author
|
@vvbandeira @maliberty Stuck?
|
Member
|
Odd it seems to have never started. pr-head does show |
The previous change unconditionally unset the RUNFILES_* env vars and relied on the /proc/self/exe fallback to find OpenROAD's runfiles. That breaks tests where OpenROAD is invoked via a wrapper (e.g. sh_test/whittle.py) whose runfiles tree already contains OpenROAD's tcl_resources_dir, because in remote-cache CI runs the real binary in execroot doesn't have an openroad.runfiles/ next to it, so the exe_path fallback fails. Probe the inherited RUNFILES_* tree for tcl_resources_dir first; only if it isn't there (the Python-wrapper case the previous commit fixed) unset the env vars and retry via exe_path. Fixes //test/orfs/gcd:gcd_whittle_test in CI. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
auto-merge was automatically disabled
April 18, 2026 08:07
Head branch was pushed to by a user without write access
Collaborator
Author
|
@maliberty bazel runfiles papercuts... 😿 |
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
maliberty
approved these changes
Apr 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

When OpenROAD is invoked by a build system that previously ran another Bazel binary (e.g. a Python wrapper in a Bazel action), the inherited RUNFILES_DIR / RUNFILES_MANIFEST_FILE env vars point to the other binary's runfiles tree. Runfiles::Create() checks those env vars first, so it resolves paths in the wrong tree.
Unsetenv the three RUNFILES_* variables before Runfiles::Create() so it falls back to the exe_path derived from /proc/self/exe.