Standalone jerbuild binaries omit transitive compiled libraries from app.boot #86
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?
Problem
A FreeBSD 15.1 amd64 service built with Jerboa 0.12.10 links successfully but cannot start when a project module imports
(std net request). The executable exits before its entry point with:The same clean rebuild also produced
Exception: library (jerboa runtime) not foundfor another standalone executable. These are runtime boot-image closure failures, separate from the FreeBSDcompile-programhang tracked in #78.Reproduction
(std net request), e.g. viajerbuild build --config ...orjerbuild binary.--version.Exception: library (std pregexp) not found.Adding
$JERBOA_HOME/libto--libdirs, and explicitly importing/referencing(std pregexp)at the entry point, did not make the standalone image start. Removing stale.so/.wpoartifacts instead caused compilation-instance mismatch errors.Likely cause
The static builder creates
app.bootfromprogram.soonly. A nested compiled dependency is then absent from the embedded boot image. A successful link is therefore insufficient evidence that the executable can load its complete runtime closure.Expected behavior
The builder should resolve and bundle the full transitive compiled-library closure in the app boot image, preserving the same compilation instances. Add a regression that builds a small executable using
(std net request)and executes it successfully on FreeBSD.Environment
ta6fb)~/.local/bin/jerboa)jerbuild build/gmake binaryThis blocks deployment of
ober/jerboa-botjail0.6.0 because its Forgejo handoff publisher needs the HTTP client.Attached: jerboa-issue-86-handoff.md (16,686 bytes; SHA-256
eba792f781e11ef24cc49ba5144ed9631a2d4c72965af764b7ef63f649895028). Downloaded the issue attachment and verified it matches the local Markdown byte for byte.Important correction to the original diagnosis: the actual CLI builder is
jerbuild.ss:do-binary-build; its default release path embeds the whole-program image, rather than using the separatelib/jerboa/build.ss:build-binaryapp.boot routine. The previously asserted app.boot cause was not established.The handoff maps upstream master
1cda118d62c1f2e23dbfbcd685fcc82b24433289(0.12.18), including the existing FreeBSD compilation-path fix from PR #84. The failing host still reports installed multicall 0.12.10. It gives exact filenames/functions/lines, commands to build the fixed multicall and rebuild all three affected consumer executables, conditional repair steps, regression and CI coverage, and an explicit closure checklist. A rebuilt current-master consumer has not yet been validated; this attachment does not claim issue #86 is resolved.Implemented and submitted for review in PR #91: #91.
Validation completed before opening the PR:
make binary,make binary-smoke-existing,make jerboa-smoke, and issue82 regression.bj-serviced,bj-release-worker, andbj-job-hostversion/help startup checks pass.FreeBSD multicall SHA-256:
a5b67135ab481b56bead8e4c621259f4357e85771deaef8d77fd733a69f30171.