Skip to content

Add NetBSD and DragonFly BSD as host platforms - #31069

Open
zakinko wants to merge 1 commit into
bazelbuild:masterfrom
zakinko:bsd-support
Open

Add NetBSD and DragonFly BSD as host platforms#31069
zakinko wants to merge 1 commit into
bazelbuild:masterfrom
zakinko:bsd-support

Conversation

@zakinko

@zakinko zakinko commented Sep 10, 2026

Copy link
Copy Markdown

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
zakinko requested a review from a team as a code owner September 10, 2026 23:19
@zakinko
zakinko requested review from gregestren and removed request for a team September 10, 2026 23:19
@github-actions github-actions Bot added team-Configurability platforms, toolchains, cquery, select(), config transitions area-EngProd Bazel CI, infrastructure, bootstrapping, release, and distribution tooling team-Rules-Java Issues for Java rules team-Rules-CPP Issues for C++ rules team-Rules-Server Issues for serverside rules included with Bazel awaiting-review PR is awaiting review from an assigned reviewer labels 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-EngProd Bazel CI, infrastructure, bootstrapping, release, and distribution tooling awaiting-review PR is awaiting review from an assigned reviewer team-Configurability platforms, toolchains, cquery, select(), config transitions team-Rules-CPP Issues for C++ rules team-Rules-Java Issues for Java rules team-Rules-Server Issues for serverside rules included with Bazel

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant