Date: 2026-10-05
Package: gnu-mach / mach-dev (Debian ports, hurd-amd64, forky/sid)
Version: GNU Mach 1.8+git20260224-up-amd64 (Debian GNU/Hurd forky/sid,
preinstalled image debian-hurd-amd64-20260314)
Severity: important - no C program including <mach.h> compiles
Summary
-------
The GNU Mach headers installed by the current Debian ports
(forky/sid) snapshot use the type processor_name_array_t in the
MIG-generated /usr/include/mach/mach_host.h, but no installed
header defines that typedef. Since /usr/include/mach.h includes
<mach/mach_host.h> at its line 37, every C program that includes
<mach.h> - directly or through any Hurd interface header such as
<hurd/trivfs.h> or <hurd/netfs.h> - fails to compile on this
snapshot.
In practice this means that no translator can be built against
the current Debian GNU/Hurd image until a workaround is applied.
Environment
-----------
$ uname -a
GNU debian 0.9 GNU-Mach 1.8+git20260224-up-amd64/Hurd-0.9 x86_64
GNU
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Hurd forky/sid"
VERSION_CODENAME=forky
Image: the official preinstalled image
debian-hurd-amd64-20260314.img (cdimage.debian.org ports),
unmodified.
Compiler: gcc (Debian 15.2.0-12) 15.2.0
Minimal reproducer
-----------------
$ cat > repro.c <<'EOF'
#include <mach.h>
int main (void) { return 0; }
EOF
$ gcc repro.c
In file included from /usr/include/mach.h:37,
from repro.c:1:
/usr/include/mach/mach_host.h:538:9: error: unknown type name
'processor_name_array_t'; did you mean
'processor_set_name_array_t'?
538 | processor_name_array_t *processors_list,
| ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/mach/mach_host.h:1092:9: error: unknown type name
'processor_name_array_t'; did you mean
'processor_set_name_array_t'?
1092 | processor_name_array_t *processors_list,
| ^~~~~~~~~~~~~~~~~~~~~~~
The two affected prototypes are server signatures generated by
MIG from mach_host.defs (both take an out-parameter named
processors_list - the host_processors family).
Analysis
--------
On the installed system the type is used but never defined:
$ grep -rn "processor_name_array_t" /usr/include/mach/
/usr/include/mach/mach_host.h:538: processor_name_array_t
*processors_list,
/usr/include/mach/mach_host.h:1092: processor_name_array_t
*processors_list,
That is the complete output: two usages, zero typedefs. Neither
/usr/include/mach/processor.h nor
/usr/include/mach/processor_info.h (nor any other installed
header) defines it, although processor_info_t itself is defined
normally.
The type corresponds to the MIG array type
type processor_name_array_t = array[] of processor_info_t;
of mach_host.defs. In a healthy installation the matching C
typedef
typedef processor_info_t *processor_name_array_t;
is emitted by the MIG header generation (or provided by
<mach/processor.h>). On this snapshot it is missing, which
looks like a regression of the MIG header generation or of the
mach-dev packaging for hurd-amd64.
Note that the sibling type processor_set_name_array_t IS
properly defined (gcc's "did you mean" suggestion finds it),
which suggests a local, mechanical omission rather than a
deliberate interface change.
Impact
------
Every Hurd translator - anything including <hurd/trivfs.h>,
<hurd/netfs.h>, or <mach.h> directly - fails to build. We hit
this while building four independent translators of the GNU AI
stack (httpfs-translator, sigmoid-neuron-translator,
data-base-translator, orchestrator-translator) inside the
official 2026-03-14 image; none of them compiled until the
workaround below was applied. Anything else on the system that
was built before the snapshot is of course unaffected, which
makes the regression easy to miss.
Workaround
----------
Define the missing typedef before any Mach or Hurd include:
#include <mach/processor_info.h>
typedef processor_info_t *processor_name_array_t;
C tolerates the identical redefinition, so the workaround stays
compatible with a fixed snapshot. The canonical fix would be to
restore the typedef to the installed headers (MIG-generated
<mach/mach_host.h> or <mach/processor.h>, wherever the snapshot
intends it to live).
The same workaround may be needed for other MIG array types if
more of them were dropped by the same generation run; we have
only audited processor_name_array_t so far.
Please keep us copied
--------------------
We maintain the GNU AI stack (gnu-ai.org), all of whose
translators are built under this image by a public CI
(gnu-ai/mistral-vm-debian-hurd driving the preinstalled image
under QEMU). We are happy to test a fixed mach-dev package or a
fixed image on short notice.
--
Claire Ivanenka <[email protected]>
GNU AI - https://gnu-ai.org
