Build xar with signed char so it works on ARM64 #355

Merged

binjovi-bot merged 1 commit from fix/xar-signed-char into trunk

2026-09-13 17:14:05 +00:00

sean commented

2026-09-13 17:10:44 +00:00

Owner

Follow-up to #353. The ARM64 zig-builder:v9 shipped an xar that printed its usage and exited 1 for every command, including xar -t, so zelnet's macOS .pkg step failed. Both Linux architectures had already been packaged as 0.10.13 by that point, so the rest of the toolchain is fine.

Cause, confirmed by probing the published image and reading upstream:

char command = 0, c;
...
while( (c = getopt_long(argc, argv, "axcVOC:vtjzf:hpPln:s:d:k", o, &loptind)) != -1 ) {

A plain char is signed on x86-64, so -1 compares equal and the loop ends. It is unsigned on ARM64, where -1 lands as 255: the loop never ends, and the next pass falls through the switch to the usage default. Upstream mackyle/xar has not changed since 2014, so this is not drift; it appeared the moment the image was built for the architecture that runs it.

-fsigned-char gives the 2014 code the char signedness it was written for. It joins the three EL10 fixes the stage already carries, and the comment explains it in the same place.

The stage now builds an archive and reads it back instead of only running xar --version. That check passed on a binary that could not archive anything, which is why v9 shipped broken.

scripts/check-binjovi-server-package.sh and scripts/lint-no-runtime-fetch.sh pass. The version floor added in #353 accepts v10 with no further edit.

bomutils/mkbom is unaffected: the failing build shows it producing the Bom successfully just before the xar step.

https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

Follow-up to #353. The ARM64 `zig-builder:v9` shipped an `xar` that printed its usage and exited 1 for **every** command, including `xar -t`, so zelnet's macOS `.pkg` step failed. Both Linux architectures had already been packaged as `0.10.13` by that point, so the rest of the toolchain is fine. Cause, confirmed by probing the published image and reading upstream: ```c char command = 0, c; ... while( (c = getopt_long(argc, argv, "axcVOC:vtjzf:hpPln:s:d:k", o, &loptind)) != -1 ) { ``` A plain `char` is **signed** on x86-64, so `-1` compares equal and the loop ends. It is **unsigned** on ARM64, where `-1` lands as 255: the loop never ends, and the next pass falls through the switch to the usage default. Upstream `mackyle/xar` has not changed since 2014, so this is not drift; it appeared the moment the image was built for the architecture that runs it. `-fsigned-char` gives the 2014 code the char signedness it was written for. It joins the three EL10 fixes the stage already carries, and the comment explains it in the same place. The stage now **builds an archive and reads it back** instead of only running `xar --version`. That check passed on a binary that could not archive anything, which is why v9 shipped broken. `scripts/check-binjovi-server-package.sh` and `scripts/lint-no-runtime-fetch.sh` pass. The version floor added in #353 accepts v10 with no further edit. `bomutils`/`mkbom` is unaffected: the failing build shows it producing the Bom successfully just before the `xar` step. https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

sean added 1 commit

2026-09-13 17:10:44 +00:00

Build xar with signed char so it works on ARM64

binjovi/ci Binjovi completed the frozen plan

Details

f718fe3493

The ARM64 zig-builder shipped an xar that printed its usage and exited 1
for every command, so the zelnet macOS .pkg step failed. Both Linux
architectures had already been packaged by then.

xar.c declares `char command = 0, c;` and loops on
`(c = getopt_long(...)) != -1`. A plain char is signed on x86_64, so the
loop ends. It is unsigned on ARM64, where -1 lands as 255: the loop never
ends, and the next pass falls to the switch default, which prints the
usage and exits. Upstream has not changed since 2014, so this appeared
the moment the image was built for the architecture that runs it.

-fsigned-char gives the code the char signedness it was written for.

The stage now builds an archive and reads it back. `xar --version`
answered on a binary that could not archive anything, so the old check
proved nothing.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

binjovi-bot merged commit f718fe3493 into trunk

2026-09-13 17:14:05 +00:00

binjovi-bot deleted branch fix/xar-signed-char

2026-09-13 17:14:05 +00:00

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

sean/builder-images!355

No description provided.

Rows
Columns