Skip to content

zephyr-cp: stop non-English builds from linking the English translation objects - #11422

Open
dhalbert wants to merge 1 commit into
adafruit:mainfrom
dhalbert:zephyr-fresh-archive
Open

dhalbert wants to merge 1 commit into
adafruit:mainfrom
dhalbert:zephyr-fresh-archive

Conversation

@dhalbert

Copy link
Copy Markdown
Collaborator

Claude found and fixed this, reviewed and tested on hardware by @dhalbert.

Every non-en_US zephyr-cp firmware built by CI contains the English compressed strings together with the other language's decompression tables. This breaks the firmware: @dhalbert tested the 10.3.1 fr build on a Feather RP2040. It enumerates CIRCUITPY but its REPL never responds because of the scrambled compressed strings; en_US works.

The cause

cpbuild.archive() updated libcircuitpython.a with ar rvs, which replaces the members named on the command line and keeps every other member. The release build reuses one build directory for all 17 languages, so after en_US each later language added its own translations-<lang>.o and autogen_display_resources-<lang>.o, but the en_US members stayed in the archive ahead of them and the linker took those. translate.c, which holds the decompression tables, is recompiled per language, so strings and tables no longer match.

Evidence from the artifacts of today's main run for adafruit_feather_nrf52840_zephyr: all 516 compressed translation symbols in the de_DE and ja ELFs have exactly the sizes they have in en_US, while a clean local de_DE build differs in 426 of them. The linker map of an incremental de_DE build shows libcircuitpython.a(translations-en_US.o).

Fix

Delete the archive, and then use ar rcs, so it only ever contains the current build's objects. The c in ar rcs prevents a warning that the archive had to be created.

The archive is now rebuilt on every build, which is under a second for ~450 objects.

Verification

  • Incremental en_US then de_DE on adafruit_feather_nrf52840_zephyr is now byte-identical to a clean de_DE build at the same path; ja matches the clean ja size, and the map shows only the current language's objects.
  • Tested by @dhalbert: adafruit_feather_rp2040_zephyr: en_US, then fr, then ja built in one directory and flashed in turn; the fr and ja REPLs work and show their languages.
  • cptools tests pass.

Affects every zephyr-cp release with translations, so this has been broken for a while.

`cpbuild.archive()` updated the archive with `ar rvs`, which replaces the members named on the command line and keeps every other member. After the en_US build of a release job, each later language added its own `translations-<lang>.o` and `autogen_display_resources-<lang>.o` but the en_US members stayed in the archive ahead of them, and the linker used the English ones. Every non-en_US zephyr-cp firmware shipped this way has the English compressed strings with another language's decompression tables; on a Feather RP2040 the 10.3.1 fr build has an unresponsive REPL.

Delete the archive before running `ar rcs`. The archive is now rebuilt on every build, under a second for ~450 objects.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@dhalbert dhalbert changed the title zephyr-cp: fix non-English builds linking the English translation objects zephyr-cp: stop non-English builds from linking the English translation objects Sep 19, 2026
@dhalbert
dhalbert requested a review from tannewt September 19, 2026 04:27
@dhalbert
dhalbert requested a review from mikeysklar September 20, 2026 02:43

@mikeysklar mikeysklar left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested this PR with 10.3.x and main, building adafruit_feather_nrf52840_zephyr en_US then fr in one directory. On a Feather nRF52840, unpatched 10.3.x fr never enumerates on USB. With this change both fr builds boot with a French REPL. Should this also go into 10.3.x?

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.

2 participants