latest-integration and latest-main musl release binaries are dynamically linked and cannot run on tester VMs #19
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_code#19
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The published hero_code_server and hero_code_admin assets named linux-musl-x86_64 on both latest-integration (target
4e37bd88) and latest-main are not static: they request the interpreter /lib/ld-musl-x86_64.so.1, so on an Ubuntu tester VM exec fails with "required file not found", and after installing the musl loader they segfault on startup. Asset md5 matches the sidecar, so this is the build, not download corruption. A plaincargo build --release --target x86_64-unknown-linux-musl -p hero_code_server -p hero_code_adminof the same commit4e37bd88produces fully static binaries (no PT_INTERP) that run fine, so the release workflow's builder environment is linking musl dynamically for this repo. Until this is fixed, a Cockpit upgrade of hero_code replaces a working binary with one that cannot start (this killed hero_code on the sandboxfull tester today; restored with a locally built static binary of the same commit).Signed-by: mik-tf mik-tf@noreply.invalid