bazel: installer for ubuntu26

[gadfort]

Summary

Update dep installer for ubuntu26.

Type of Change

• Bug fix

Impact

Ensures the bazel build completes on a ubunu26 system

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.
• I have signed my commits (DCO).

Related Issues

#10761

[gemini-code-assist]

Code Review

This pull request updates etc/DependencyInstaller.sh to support Ubuntu 26.04+ by installing libxml2-dev instead of libxml2 and creating a compatibility symlink libxml2.so.2 for the prebuilt LLVM toolchain. Feedback was provided regarding the use of a pipeline (ls | grep | head) which can cause the script to crash under set -eo pipefail if no matching files are found; a pure Bash loop with globbing was suggested as a safer and more robust alternative.

[gemini-code-assist]

Since set -euo pipefail is active at the top of the script, any command in a pipeline that exits with a non-zero status will cause the entire pipeline to fail, which in turn triggers set -e and terminates the script immediately.

If ls "${libdir}"/libxml2.so.* does not match any files (for example, if libxml2 is not installed, is in a different directory, or if the directory doesn't exist), ls will exit with a non-zero status. This will cause the pipeline to fail and the script to crash.

Using a pure Bash loop with globbing avoids spawning external processes (ls, grep, head), is completely safe under set -eo pipefail, and is more efficient. Additionally, when searching for libraries in a shared prefix on Linux, we should account for multiarch layouts by including globs for architecture-specific subdirectories (e.g., "${libdir}"/*/libxml2.so.*).

Suggested change

	local libxml2_so
	libxml2_so=$(ls "${libdir}"/libxml2.so.* 2>/dev/null \
	| grep -v 'libxml2.so.2$' | head -n1)
	local libxml2_so=""
	local f
	for f in "${libdir}"/libxml2.so.* "${libdir}"/*/libxml2.so.*; do
	if [[ -e "${f}" && "${f}" != *"/libxml2.so.2" ]]; then
	libxml2_so="${f}"
	break
	fi
	done

References

1. When cleaning up or searching for libraries in a shared prefix on Linux, account for multiarch layouts by including globs for architecture-specific subdirectories (e.g., "lib/*/").

[oharboe]

@maliberty if we merged the stubbing out of libxml then we could forget all about this and ditch the kludge on next llvm. uodate

[oharboe]

@hzeller I think the libxml stubbing hack would have been preferable. Add hack and delete it on next llvm upgrade and forget all about it, more hermetic too.

[gadfort]

@oharboe unfortunately it seems the llvm is built assuming a particular name for the library and the linker fails without this hack on ubuntu26 (it's fine elsewhere). If they fix it upstream that would be great too.
it is easy to revert assuming a fix is available in the future.

[oharboe]

It is fixed in LLVM main, it just missed the llvm release we are using in bazel by a hair.

[gadfort]

@oharboe ahh, thats good, in that case this only needs to live for a while (hopefully) until it's available

[oharboe]

@gadfort If you want to give it go to see if you can forget all about this libxml window stuff #9809

[gadfort]

@oharboe that PR is closed, not sure it's worth debugging further on my end, others are much better suited to find the upstream fix.

[oharboe]

@oharboe that PR is closed, not sure it's worth debugging further on my end, others are much better suited to find the upstream fix.

I can re-open it if there's interest. It is what we're running with on Ubuntu 26.04 and it also fixes hermeticy issues with OpenROAD and bazel-orfs.

Works great!

[maliberty]

If there is a later release we can use to bypass all this that would be great too.

[oharboe]

If there is a later release we can use to bypass all this that would be great too.

Yes: first thing to do is to try to upgrade LLVM bazel uses, if that doesn't work, then either apply the hack or we can suffer the pain meanwhile in various other ways...

[gadfort]

supposedly: bazel-contrib/toolchains_llvm#657 so maybe 1.7 or 1.8

[oharboe]

The Five Stages of Bazel Dependency Grief

From Upstream Purist to AI-Assisted Zen

---

Stage 1: Denial (The Upstream Purist)

• The Mindset: "Local patches are a code smell. I am a professional; I will fix the root cause upstream."
• The Reality: You fork the upstream repository, meticulously craft a textbook-perfect BUILD.bazel file, test it across three toolchains, and submit a pristine Pull Request. You close your laptop feeling like a model citizen of the open-source ecosystem.

Stage 2: Anger (The Review Limbo)

• The Mindset: "It is literally four lines of Starlark! Why is this sitting unreviewed for six months?!"
• The Reality: The automated stale-bot threatens to close your PR. When a maintainer finally responds, it’s either: "We use CMake and have no interest in supporting Bazel," or an invitation to a 40-comment thread nitpicking the indentation of a build system they admit they do not understand.

Stage 3: Bargaining (The "Pretty Please" Campaign)

• The Mindset: "If I just offer to maintain their Bazel CI pipeline for them, they'll have to say yes."
• The Reality: You start debasing yourself. You ping the PR every 14 days with a polite "Gentle bump!" You open side-conversations in the Bazel Slack asking if anyone knows a guy who knows the maintainer. You start offering to rewrite their docs just to get a .bzl file merged.

Stage 4: Depression (The Cognitive Tax)

• The Mindset: "I am no longer a software engineer. I am a full-time Starlark archaeologist."
• The Reality: You stare at your MODULE.bazel. It contains 34 single_version_override blocks pointing to a graveyard of your own personal GitHub forks. You realize that the global interest in Bazel-ifying this specific C++ image-parsing library is roughly four people on Earth. The mental weight of tracking which fork belongs to which branch begins to cause genuine physical fatigue.

Stage 5: Acceptance (The Automated Equilibrium)

• The Mindset: "My employer pays me to ship a product, not to reform the open-source build community."

The Enlightened Workflow:

1. The Hack: You tell Claude: "Write an ad-hoc Bazel patch for libxyz v1.4."
2. The Receipt: You have Claude write and submit the upstream PR. Crucially, you no longer care if a human ever reviews it. 3. The Immutable Anchor: You grab the static GitHub .diff URL generated by that PR.
3. The Pin: You paste that URL directly into your MODULE.bazel patches = [...] attribute.

---

The Zen Takeaway: > You have made peace with The Law of Conservation of Patches. Over a 12-month period, some of your Claude-generated PRs will randomly get merged upstream by a bored maintainer; simultaneously, new upstream updates will break other libraries, requiring fresh Claude patches.
You will forever sit atop a roughly time-constant, undulating mound of AI-managed patches—and for the first time in three years, your build passes on the first try.

[oharboe]

supposedly: bazel-contrib/toolchains_llvm#657 so maybe 1.7 or 1.8

Waiting worked! https://registry.bazel.build/modules/toolchains_llvm/1.8.0 is out

[oharboe]

Just to be clear: I'm enormously appreciative that @maliberty takes the time to push back on simply accepting cruft patches that supposedly clean themselves up with future upgrades and create pressure to update bazel bcr and fix things upstream.

It greatly simplifies my life and reduces the over time constant size pile of patches that I have to maintain.

Matt is providing the "community gradient" towards whittling down patches over time...

[gadfort]

@oharboe unfortunately 1.8.0 with 21.1.8 still needs this hack to function. @maliberty until the upstream is fixed, this atleast allows ubuntu26 machines to be able to compile openroad on bazel.

[oharboe]

Or apply the libmxl hack I made: removes system dependency.