Fix the Cross-build Kernel CI workflow

[laffer1]

The Cross-build Kernel workflow has failed on every master run for months. Three independent causes, one commit each:

1. ck compat headers gate on __MidnightBSD__. Five sys/contrib/ck/include/ck_*.h headers fell through to hosted <stdint.h>/<stdbool.h> under -nostdinc when the macro was missing. Keyed the branch on _KERNEL like the earlier ck_limits.h fix (8b8a33b).

2. arm64 Ubuntu passes KERNEL_FLAGS=CFLAGS+=.... A command-line CFLAGS+= makes CFLAGS command-line-owned in bmake, so every CFLAGS line in kern.pre.mk is dropped and the kernel loses -nostdinc and all -I paths (sys/cdefs.h file not found in genoffset.c). The two -idirafter hacks were workarounds for cause 1, so they are removed.

3. External compilers never define __MidnightBSD__. The cross build drives upstream clang-18 with a *-unknown-freebsd13.4 triple, which predefines __FreeBSD__ only. The whole kernel tree keys on __MidnightBSD__ (ACPICA acenv.h was the first to fail with Unknown target environment, followed by netmap, ipfilter, dtrace, ...). When bsd.compiler.mk reports the external compiler has no __MidnightBSD_cc_version, Makefile.inc1 now adds -D__MidnightBSD__=<N> to XCFLAGS, with N taken from the triple's OS major version exactly as our own clang does. Native builds are unaffected.

Causes 1 and 2 were verified locally (all ck_*.o, genassym.o, subr_epoch.o, subr_pctrie.o with CC='clang -U__MidnightBSD__'). Cause 3 was verified via bmake -f Makefile.inc1 -V XCFLAGS for simulated external and native compilers; the PR's CI run is the end-to-end test.

AI-Assisted-by: Claude Fable 5.1
Fixes: f3f40cd ci: add clang resource headers for arm64 kernel build
Fixes: 4f31c80 ci: add cross-build headers for Linux arm64 kernel builds

🤖 Generated with Claude Code

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Fixes cross-build kernel CI by making CK headers recognize any _KERNEL build regardless of predefined OS macros, preventing hosted-header failures with upstream clang triples, and removing the arm64 Ubuntu CFLAGS+= workaround that caused bmake to discard the kernel’s normal include flags.

Flow diagram for cross-build kernel header selection

flowchart TD
    A["Cross-build kernel compilation"] --> B{_KERNEL defined?}
    B -->|Yes| C["CK headers include sys kernel headers"]
    B -->|No| D["CK headers include hosted standard headers"]
    C --> E["Works with upstream clang FreeBSD triple"]
    D --> F["Uses stdbool.h stddef.h stdint.h stdlib.h or string.h"]

Loading

Flow diagram for corrected arm64 kernel build flags

flowchart TD
    A["Cross-build workflow"] --> B["Build kernel with normal bmake flags"]
    B --> C["kern.pre.mk supplies -nostdinc and -I paths"]
    C --> D["Kernel and CK headers resolve sys includes"]
    D --> E["genassym.o and kernel objects compile"]

Loading

File-Level Changes

Change	Details	Files
Make CK compatibility headers select kernel-specific MidnightBSD interfaces based on the generic kernel build marker rather than compiler vendor macros.	Update five CK headers to use _KERNEL for sys/* includes. Preserve Linux kernel handling in ck_stdint.h while broadening the BSD kernel branch. Avoid fallback hosted headers that are unavailable under -nostdinc.	sys/contrib/ck/include/ck_stdbool.h sys/contrib/ck/include/ck_stddef.h sys/contrib/ck/include/ck_stdint.h sys/contrib/ck/include/ck_stdlib.h sys/contrib/ck/include/ck_string.h
Remove the arm64 Linux CI compiler-include workaround now that kernel include selection is corrected.	Stop appending CFLAGS+= -idirafter resource and cross-build include paths for the arm64 Ubuntu job. Rely on the normal kernel build flags, avoiding command-line CFLAGS ownership that suppresses kern.pre.mk flags such as -nostdinc and required include paths.	.github/workflows/cross-bootstrap-tools.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook