bazel-orfs: bump#10516
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the BAZEL_ORFS_COMMIT hash in MODULE.bazel and advances the src/sta subproject commit. The MODULE.bazel.lock file has been updated accordingly to reflect these dependency changes, including the addition of the openroad_qt target mapping. I have no feedback to provide as there are no issues identified in these changes.
oharboe
force-pushed
the
bazel-orfs-bump-2
branch
from
da692a8 to
2b9cc7d
Compare
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
oharboe
force-pushed
the
bazel-orfs-bump-2
branch
from
2b9cc7d to
ad38292
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request cleans up the Bazel configuration by removing temporary registry entries from .bazelrc and updating dependency versions in MODULE.bazel. Specifically, sv-lang is updated to version 10.0.1-20260316-f04e8156, yosys is upgraded to 0.64, and the BAZEL_ORFS_COMMIT pin is updated. There are no review comments, and I have no additional feedback to provide.
|
out of sight out of mind for now |
|
needs more work... QoR drifted w yosys |
scip 9.2.3's vendored tinycthread.h exposes the bare identifiers
`once_flag` and `call_once`, which are reserved by the C11 standard
library (<threads.h>). Modern C runtimes provide those names as real
typedefs/functions, and any include order that pulls <stdlib.h>
alongside scip's polyfill produces a typedef redefinition / conflicting
declaration at compile time.
Upstream scip already fixed this in commit cc917e07 ("prefix also
once_flag and call_once with TNY", 2026-02-16, closes scipopt/scip#191)
by namespacing the polyfill's internal symbols with a TNY_ prefix.
That fix is on scip master but not in any tagged release yet, so
backport it via a single_version_override patch.
The override is self-documented with a drop-when condition: remove it
(and the patch file) once a post-9.2.3 scip release containing the
rename lands on the Bazel Central Registry.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The initial CI run on this PR failed two jobs for infrastructure
reasons unrelated to the patch:
- Clang-Tidy-Bazel: GitHub Actions runner ran out of disk while
extracting LLVM-20.1.8-Linux-X64.tar.xz ("No space left on
device").
- docs/readthedocs.org:openroad: Read the Docs npm install of
@mermaid-js/mermaid-cli failed with ECONNRESET against
registry.npmjs.org.
Pushing an empty commit to retrigger CI without rewriting history.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Long-form comments restated what `single_version_override`, C11 <threads.h>, and BCR are. Cut to the anchor (upstream SHA) and the drop condition. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Stack PR The-OpenROAD-Project#10516 on top of PR The-OpenROAD-Project#10522 so the scip TNY_ prefix backport is in the build graph during CI for the orfs/yosys/sv-lang bumps. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Head branch was pushed to by a user without write access
sed 4.9's vendored gnulib polyfills (lib/memchr.c) gate `#undef memchr` on `#ifdef _LIBC`. Outside _LIBC, glibc 2.43+ leaves the C11 _Generic wrapper macro for memchr active, so the polyfill's `#define __memchr memchr` followed by `void * __memchr (...)` expands through the macro and fails to compile. Drop the _LIBC gate so the undef runs everywhere. Drop this override once upstream gnulib lands an unconditional undef (or BCR's sed overlay stops compiling the affected polyfills). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Pull in the sed gnulib polyfill undef fix (PR The-OpenROAD-Project#10523) so the orfs flow builds locally and `bazelisk run //test/orfs/gcd:gcd_update_rules` can refresh the wirelength rule baseline for the yosys 0.64 / orfs bump. # Conflicts: # MODULE.bazel.lock
Regenerated via `bazelisk run //test/orfs/gcd:gcd_update_rules` after the bazel-orfs/yosys 0.64 bump shifted gcd QoR. Notable deltas: detailedroute wirelength 1403 -> 1625, synth area 44.3 -> 47.6, finish setup ws -71 -> -79.5. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com> # Conflicts: # MODULE.bazel.lock
There was a problem hiding this comment.
There is no change to the yosys version in this PR
|
how is this related to #10523 ? |
|
|
||
| bazel_dep(name = "yosys", version = "0.62.bcr.2", dev_dependency = True) | ||
| bazel_dep(name = "yosys", version = "0.64", dev_dependency = True) | ||
|
|
|
The problem to merge here is that you have included another PR that I am not ready to merge so I'll hold this one until it is resolved. |
All good. The main urgency for me here was to diagnose, get us unstuck and have a record of the surprisingly few Ubuntu 26.04 LTS snags. |
|
No activity, so closing. |
2 participants
No description provided.