Oskar Hahn (Aug 05 2026 at 21:00): Oskar Hahn (Aug 05 2026 at 21:00):Hi, I am trying to build a go platform for the new compiler. But I run into problems, that I do not understand.
The Code is here: https://github.com/ostcar/roc-platform-template-go/tree/new_compiler
The current code does not call into roc. It should just start.
I am able to build the libhost.a with:
CGO_ENABLED=1 CC="zig cc -target x86_64-linux-musl" go build -C host -buildmode c-archive -tags netgo,osusergo -o ../platform/targets/x64musl/libhost.a
And roc also builds some binary:
roc build examples/echo.roc
0 errors and 0 warnings found in 216ms while successfully building:
echo
But when I try to call it, I get a segmentation fault:
./echo
Segmentation fault (core dumped) ./echo
I don't know, what the problem could be. When discussing it with the AI, it sounds like it could be a conflict between the musl signal handling and the go signal handling. But I found a lot of other projects, that successfully combine go and musl.
Do you have other ideas, what the problem could be or how to debug it further?
Luke Boswell (Aug 05 2026 at 22:17):You can ask an AI Agent to drive a debugger like gdb or lldb and help you isolate the segfault.
Aurélien Geron (Aug 05 2026 at 22:21):Walking people through the steps to debug (and possibly fix) segfaults would be a great topic for the next meetup!
Aurélien Geron (Aug 05 2026 at 22:22):And a "how-to-best-contribute" talk would be great too. :folded_hands:
Luke Boswell (Aug 05 2026 at 22:25):the checked-in musl crt1.o jumps into Go’s c-archive entry without the initialization sequence Go expects.
Possible suspect
Luke Boswell (Aug 05 2026 at 22:50):I think I've got Go working... there was a lot to modify and I had to vendor a some things from Zig.
I'm setting up CI now with the full cross-compiled matrix so we can be sure it's working on every target.
Luke Boswell (Aug 05 2026 at 22:56):As I suspected we will need to add mingw as a new roc target for Windows support
Luke Boswell (Aug 06 2026 at 00:39):Done https://github.com/lukewilliamboswell/roc-platform-template-go
I'll make an announcement too so it's easier to find
Oskar Hahn (Aug 17 2026 at 13:11):Thank you. That is amazing. Sorry, that I was not able to respond earlier.
What I do not like is, that there have to be binary-blobs in the source tree. I think, they are potential security risks, specially, when the code from the template gets copied around for other platforms.
Do you think, it would be beneficial to change the platform in a way, that is does not depend on libc and the other binary parts? I think this should be possible, since go has no dependency to libc.
Here is an example, that uses the go allocator instead of c-malloc. Maybe something similar would be possible for the startup-logic.
Anton (Aug 17 2026 at 13:14):What I do not like is, that there have to be binary-blobs in the source tree.
Yes, I would like to avoid this too
Anton (Aug 17 2026 at 13:14):Here is an example,
Did you forget a link here @Oskar Hahn?
Oskar Hahn (Aug 17 2026 at 13:15):Ups. Yes, here is the diff, that uses go alloc: https://github.com/lukewilliamboswell/roc-platform-template-go/compare/main...ostcar:go_memory
Anton (Aug 25 2026 at 16:16):What I do not like is, that there have to be binary-blobs in the source tree.
I will look at this now
Luke Boswell (Aug 25 2026 at 20:20):What is the issue with binary blobs? Is it provenance? I vendor the libs once and then never need to change them... is it that a zero-day might be discovered in a library version?
Oskar Hahn (Aug 26 2026 at 06:02):I am thinking about the attack on xz utils: https://en.wikipedia.org/wiki/XZ_Utils_backdoor
It used binary blobs in the test code of the repo, to create a ssh-backdor.
If there are binary blobs, that are copied around for every platform and are executed with every roc program build with that platform, this seams like a easy attack vector. Only the person committing the binary blob knows, that there is no malicious code in it. Every other person has to trust it.
Luke Boswell (Aug 26 2026 at 06:26):Would you be more comfortable if there was no binary blobs checked in, but there was some kind of nix deterministic build script that is used instead?
How do you verify the binary blobs in a packaged Roc release are the correct ones you expect? I assume you would build the platform release yourself to confirm the content hash is identical?
Luke Boswell (Aug 26 2026 at 06:31):I include instructions in my platform and a script so anyone can verify the hashes for those libraries
Anton (Aug 26 2026 at 10:01):Would you be more comfortable if there was no binary blobs checked in, but there was some kind of nix deterministic build script that is used instead?
This is basically what I am doing
Anton (Aug 26 2026 at 10:03):What is the issue with binary blobs?
Because there is no text diff, a malicious change of the file by an outside contributor can be missed easily.
Luke Boswell (Aug 26 2026 at 10:33):Well... as of this GH action https://github.com/lukewilliamboswell/roc-platform-template-go/actions/runs/32958436502/job/98145216010
I believe I can now claim SLSA Level 3 (the highest level) of SLSA for the Go Platform Template (specifically the vendored libraries) which is a standardised security framework Supply-chain Levels for Software Artifacts
Luke Boswell (Aug 26 2026 at 10:41):Here is an example of how you can check the signatures
$ gh attestation verify platform/targets/x64musl/libc.a --repo lukewilliamboswell/roc-platform-template-go
Loaded digest sha256:29f80c80b042e53240d80aeaac7eab12d4d412db142c9f5167ef2e93c8689d1c for file://platform/targets/x64musl/libc.a
Loaded 4 attestations from GitHub API
The following policy criteria will be enforced:
- Predicate type must match:................ https://slsa.dev/provenance/v1
- Source Repository Owner URI must match:... https://github.com/lukewilliamboswell
- Source Repository URI must match:......... https://github.com/lukewilliamboswell/roc-platform-template-go
- Subject Alternative Name must match regex: (?i)^https://github\.com/lukewilliamboswell/roc-platform-template-go/
- OIDC Issuer must match:................... https://token.actions.githubusercontent.com
✓ Verification succeeded!
The following 4 attestations matched the policy criteria
- Attestation #1
- Build repo:..... lukewilliamboswell/roc-platform-template-go
- Build workflow:. .github/workflows/runtime-provenance.yml@refs/heads/main
- Signer repo:.... lukewilliamboswell/roc-platform-template-go
- Signer workflow: .github/workflows/runtime-provenance.yml@refs/heads/main
- Attestation #2
- Build repo:..... lukewilliamboswell/roc-platform-template-go
- Build workflow:. .github/workflows/runtime-provenance.yml@refs/heads/main
- Signer repo:.... lukewilliamboswell/roc-platform-template-go
- Signer workflow: .github/workflows/runtime-provenance.yml@refs/heads/main
- Attestation #3
- Build repo:..... lukewilliamboswell/roc-platform-template-go
- Build workflow:. .github/workflows/runtime-provenance.yml@refs/heads/fix/runtime-provenance-zig-download
- Signer repo:.... lukewilliamboswell/roc-platform-template-go
- Signer workflow: .github/workflows/runtime-provenance.yml@refs/heads/fix/runtime-provenance-zig-download
- Attestation #4
- Build repo:..... lukewilliamboswell/roc-platform-template-go
- Build workflow:. .github/workflows/runtime-provenance.yml@refs/heads/fix/runtime-provenance-zig-download
- Signer repo:.... lukewilliamboswell/roc-platform-template-go
- Signer workflow: .github/workflows/runtime-provenance.yml@refs/heads/fix/runtime-provenance-zig-download
So I do not agree that it is now possible for anyone to modify those files maliciously, you can fully and independently verify the supply chain and you don't need to trust me at all (just GitHub's build environment, which I am told it certified at the highest level :sweat_smile: )
Luke Boswell (Aug 26 2026 at 10:44):I would prefer this over Nix
Luke Boswell (Aug 26 2026 at 10:50): Luke Boswell (Aug 26 2026 at 10:57):Also -- I forgot to mention, as of today the Go platform also supports Windows :tada:
This is a pretty epic milestone tbh, it's taken a long time to thread the mingw target through the compiler upstream and get everything working. At least, it worked when I tested it and it CI but I would say it's still early days and we may find more issues with mingw linking etc.
Anton (Aug 26 2026 at 11:09):Luke Boswell said:
I would prefer this over Nix
Yeah Nix doesn't work on windows so that's not possible.
Anton (Aug 26 2026 at 11:18):Feedback from Opus xhigh session-transcript-2026-08-26.md
The second part is the most interesting, where I asked about designing a solution suited for random people making a Roc platform in a way that makes it easy to avoid security mistakes.
Luke Boswell (Aug 26 2026 at 11:23):Nice, I can iterate on this more tomorrow.
I'm keen to iterate on the Go platform hardening so I can have a "checklist" and pattern I can roll across everything.
Last updated: Sep 03 2026 at 15:16 UTC