Add jni_md_header for NetBSD and DragonFly BSD - #381
Open
zakinko wants to merge 1 commit into
Open
Conversation
The :jni pulls the machine-dependent jni_md.h out of the JDK per host, with a java_runtime_files target and a select arm for each platform. FreeBSD and OpenBSD are there; add NetBSD and DragonFly, whose JDKs ship include/netbsd/jni_md.h and include/dragonfly/jni_md.h just as the others do, so that bazel's native code builds against the right header when it is bootstrapped on those hosts. The @bazel_tools//src/conditions:netbsd and :dragonfly settings this selects on are added to Bazel itself in a companion change; os:dragonfly comes from bazelbuild/platforms#143.
zakinko
added a commit
to zakinko/bazel
that referenced
this pull request
Sep 10, 2026
Bazel already builds and runs on FreeBSD and OpenBSD; this extends the
same host support to NetBSD and DragonFly BSD, so that a bazel built
from source with scripts/bootstrap runs natively there.
The changes are the same shape as the existing FreeBSD/OpenBSD ones:
- OS.java learns NETBSD and DRAGONFLY and counts them POSIX-compatible;
AutoCpuConverter, ConfigExpander, ConstraintConstants, JniLoader and
BazelRuleClassProvider gain the matching arms (default shell, PATH,
the @platforms//os constraint, the libunix_jni.so load).
- src/conditions gains netbsd and dragonfly config_settings, used by the
C++ client, the native JNI library, singlejar and the sandbox stub to
pick the BSD sources the way freebsd/openbsd already do.
- blaze_util_bsd.cc: NetBSD dropped statfs(2), so WarnFilesystemType uses
statvfs(2), which carries f_fstypename all the same; neither NetBSD nor
DragonFly offers a way for a process to find its own executable, so both
fall back to argv[0] like OpenBSD. STANDARD_JAVABASE points at the usual
JDK location on each.
- unix_jni_bsd.cc: DragonFly's libc defines only the _file extattr
variants, not the _link ones called here, so HAVE_EXTATTR stays off
there; sysctlbyname(3) is present. NetBSD leaves both off for now.
- process-tools-darwin.cc: NetBSD exposes process listings through
KERN_PROC2 and struct kinfo_proc2, whose pid is in p_pid.
- md5.h, singlejar/{diag.h,zip_headers.h,mapped_file_posix.inc}: both are
<sys/endian.h> / err.h platforms like the other BSDs.
- md5_netbsd.sh doubles md5(1) the way md5_openbsd.sh does, since NetBSD
has neither md5sum nor GNU coreutils.
DragonFly's config_settings reference @platforms//os:dragonfly, which is
added by bazelbuild/platforms#143; until that is released the DragonFly
selects will not resolve on other platforms. NetBSD needs nothing new
from platforms (os:netbsd already exists). The jni_md_header targets come
from a companion rules_java change (bazelbuild/rules_java#381).
Bootstrapped from source and run on NetBSD 11.0/amd64. Also bootstrapped
and run on DragonFly 6.4 with platforms#143 applied, on which the whole
abseil test suite passes; that host is no longer available to re-verify
the exact form of this change.
zakinko
added a commit
to zakinko/pkgsrc-zakinko
that referenced
this pull request
Sep 11, 2026
single_version_override で当てている四枚は、どれも upstream へ出してある。 名前が platforms_netbsd.patch のままだと、その PR が入ったかどうかが名前から 引けず、マージされた後も抱え続けることになる。番号を名前にすると、当てる 先が直った瞬間に当て物が当たらなくなって build が止まるので、そこで気づける。 platforms-pr142-pr143 bazelbuild/platforms#142 と #143 rules_java-pr381 bazelbuild/rules_java#381 rules_go-pr4711 bazel-contrib/rules_go#4711 (9/9 merged) zstd_jni-netbsd upstream に出していない rules_go#4711 は master に入っているが、最新の release は v0.63.0 (8/16) で まだ含まれていない。ここは 0.59.0 を pin しているので、版を上げられるように なったら当て物ごと落とせる。 名前は MODULE.bazel と toolchain_local/BUILD の exports_files の二箇所で 効くので、両方を書き換えた。どの PR がどれかは BUILD のコメントに置いた。 当て物の本体には書いていない。bazel の patch 実装が先頭の地の文を読み飛ばす かを確かめていないので、賭けないことにした。
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
1 participant
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.
The :jni target pulls the machine-dependent jni_md.h out of the JDK per
host, with a java_runtime_files target and a select arm for each
platform. FreeBSD and OpenBSD are there; this adds NetBSD and DragonFly,
whose JDKs ship include/netbsd/jni_md.h and include/dragonfly/jni_md.h
just as the others do, so bazel's native code builds against the right
header when it is bootstrapped on those hosts.
The @bazel_tools//src/conditions:netbsd and :dragonfly settings this
selects on are added to Bazel itself in a companion change
(bazelbuild/bazel#31069); os:dragonfly comes from bazelbuild/platforms#143.