Skip to content

Do not build on the BSDs: hwinfo has no backend for them - #3

Merged
jcelerier merged 1 commit into
mainfrom
fix/freebsd
Aug 16, 2026
Merged

Do not build on the BSDs: hwinfo has no backend for them#3
jcelerier merged 1 commit into
mainfrom
fix/freebsd

Conversation

@jcelerier

@jcelerier jcelerier commented Aug 16, 2026

Copy link
Copy Markdown
Member

This add-on is the single thing that stops ossia/score from compiling on FreeBSD. With it out of the way, the rest of the tree builds and links cleanly there.

What is broken

hwinfo picks a backend in include/hwinfo/platform.h:

#if defined(unix) || defined(__unix) || defined(__unix__)
#define HWINFO_UNIX
#endif

The backend it calls "unix" is really the Linux one — every file under src/linux/ reads /proc and /sys, and two of them use interfaces that only exist on Linux:

file uses FreeBSD equivalent
src/linux/network.cpp <netpacket/packet.h>, AF_PACKET <net/if_dl.h>, AF_LINK
src/linux/ram.cpp sysconf(_SC_AVPHYS_PAGES) sysctl vm.stats.vm.v_free_count

FreeBSD defines __unix__, so it selects that backend and those two files fail:

src/linux/network.cpp:8:10: fatal error: 'netpacket/packet.h' file not found
src/linux/ram.cpp:29:37: error: use of undeclared identifier '_SC_AVPHYS_PAGES'

Why skip rather than shim

I compiled every hwinfo source on FreeBSD 15.0 one by one — those two are the only failures, so a pair of shims in hwinfo.cmake would make it build. But it would not make it work: the files that do compile read /proc/cpuinfo, /proc/stat, /proc/meminfo, /sys/class/net, /sys/class/drm, /sys/block, /sys/class/power_supply, /sys/devices/virtual/dmi. None of those are there on a FreeBSD box, so the add-on would ship a device tree that is empty end to end.

The fix worth having is a real BSD backend upstream in lfreist/hwinfogetifaddrs + AF_LINK for the network side, sysctl(3) (hw.physmem, vm.stats.vm.*, hw.model, kern.disks, kern.osrelease) for the rest. That is a backend, not a shim, and it does not belong in this repository. Until it exists, do not build the add-on there.

The change

One guard in CMakeLists.txt, next to the existing EMSCRIPTEN one:

if(CMAKE_SYSTEM_NAME MATCHES "BSD|DragonFly")
  message(STATUS "score-addon-sysinfo: hwinfo has no ${CMAKE_SYSTEM_NAME} backend, skipping")
  return()
endif()

Nothing on Linux, macOS or Windows is touched — CMAKE_SYSTEM_NAME is Linux / Darwin / Windows there.

How it was verified

In a FreeBSD 15.0 VM built from the same vmactions/freebsd-builder image the CI uses, with the 265 packages .github/workflows/bsd.yml installs:

  • every hwinfo translation unit compiled individually with c++ -std=c++20 → exactly the two errors above, nothing else;
  • a full ci/freebsd.build.sh of score with this add-on present and this patch applied → configures (score-addon-sysinfo: hwinfo has no FreeBSD backend, skipping), compiles and installs.

Note that ossia/score's FreeBSD job never noticed any of this: ci/freebsd.build.sh exited 127 on its shebang and the workflow swallowed the status. That half is fixed in ossia/score#2213; this PR should land first, otherwise that one turns the job red.

hwinfo ships three backends and picks one in include/hwinfo/platform.h.
The one it calls "unix" is really the Linux one - it reads /proc and /sys
everywhere, src/linux/network.cpp includes <netpacket/packet.h> and filters
getifaddrs() on AF_PACKET, and src/linux/ram.cpp asks sysconf() for
_SC_AVPHYS_PAGES. None of that exists on FreeBSD, which has <net/if_dl.h>
and AF_LINK for the first and the vm.stats.vm sysctls for the second.

platform.h nevertheless keys that backend off __unix__, so FreeBSD selects
it and those two files fail to compile:

  src/linux/network.cpp:8:10: fatal error: 'netpacket/packet.h' file not found
  src/linux/ram.cpp:29:37: error: use of undeclared identifier '_SC_AVPHYS_PAGES'

Everything else in hwinfo does compile there, but it would only read paths
that a FreeBSD system does not have, so shimming the two files would buy an
add-on whose whole device tree is empty. The fix worth having is a real BSD
backend upstream in lfreist/hwinfo; until then, skip the add-on.

This add-on was the only thing keeping score from building on FreeBSD - the
rest of the tree compiles and links there once it is out of the way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jcelerier

Copy link
Copy Markdown
Member Author

Verified in a FreeBSD 15.0 VM (same vmactions/freebsd-builder image ossia/score's job uses, same packages), building the add-on inside a real score tree.

Before, ninja score_addon_sysinfo_hwinfo gets 42 of 44 objects and then:

[43/44] Building CXX object .../hwinfo/src/linux/network.cpp.o
FAILED: [code=1]
  .../src/linux/network.cpp:8:10: fatal error: 'netpacket/packet.h' file not found
[44/44] Building CXX object .../hwinfo/src/linux/ram.cpp.o
FAILED: [code=1]
  .../src/linux/ram.cpp:29:37: error: use of undeclared identifier '_SC_AVPHYS_PAGES'
ninja: build stopped: subcommand failed.

Those 42 are the ones that do compile — the whole apple and windows backends compile to nothing there, and the rest of src/linux/ builds fine but only reads procfs and sysfs paths FreeBSD does not have. Hence skipping rather than shimming.

After:

 -- score: configuring score-addon-sysinfo
-- score-addon-sysinfo: hwinfo has no FreeBSD backend, skipping

and ci/freebsd.build.sh then compiles, links and installs the whole of score, ossia-score binary included.

The Ubuntu / Windows / JIT checks on this PR are red on main too (see the runs of 2026-08-08); this patch adds a CMAKE_SYSTEM_NAME MATCHES "BSD|DragonFly" guard and touches nothing else, so it cannot be the cause.

@jcelerier
jcelerier merged commit e9864b0 into main Aug 16, 2026
1 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant