we've discussed before wanting to build roc
with musl libc on Linux, so that it works across distros
also we still need to bundle llvm and it's looking like also we'll want to bundle lld
both of which are part of the same project, but we'd need to compile them with musl and use those binaries as dependencies that end up in our final zig output
(that is, in our final binary produced by Zig)
I know the zig compiler itself already builds llvm from source with musl, so presumably we can reuse the same process - and seems likely it could be adapted to work with lld too, since lld is also part of the llvm project
I think it would be great if we could be building on Linux with musl and full static linking as early as possible, and verify it with ci (like, fail ci if any dynamic dependencies are detected in the final output executable)
and I'd like to similarly verify that our only dynamic dep on macOS is libSystem, and on windows that it's whatever the equivalent of libSystem is there. (I think I remember Windows having some dependency you're always expected to link dynamically bc they don't guarantee syscall stability the way Linux does.)
this would mean we'd never accidentally introduce dynamic deps when introducing third party packages or anything like that
and we could be confident that roc
can (finally!) be downloaded and used immediately on any freshly installed OS, with nothing else needing to be installed
I think it would be great if we could be building on Linux with musl and full static linking as early as possible, and verify it with ci (like, fail ci if any dynamic dependencies are detected in the final output executable)
Yes please!
I'd like to have a crack at setting up our build pipeline, or make a start on the roc cli in zig.
Specifically bundling lld
and compiling an app (using a stubbed app.o
) for Linux, Windows, macOS.
love it! :heart_eyes:
I'd ask Andrew about bundling lld
with musl specifically
he definitely knows the best way to do that in Zig
@Andrew Kelley -- what's the best way to ask you about this? :smiley:
My plan was to dig around and explore a little to scope it out.
I wonder if we could use zig ld
or something like @Jakub Konka 's bold
? these are all written in zig.
oh yeah also we should look into bundling libunwind
too for backtracing
https://github.com/libunwind/libunwind
Luke Boswell said:
Andrew Kelley -- what's the best way to ask you about this? :smiley:
My plan was to dig around and explore a little to scope it out.
I don't mind the occasional ping here, I'm happy to help. If it gets too much I'll turn notifications off
Just double checking this, musl is only a linux thing, right?
So for mac and windows, there is no change.
If so, my gut feel is we should just make our ci script at a minimum build the compiler for the N different targets we want to support.
I guess we could also default to musl on linux, but that doesn't specifically feel necessary.
To do so would just require modifying the build script to detect when it is being built on linux and then pick the right version of musl based on the architecture. I don't think that has any specific gains over building for the musl target we care about in CI.
I'll get started on setting up the CI for the new compiler tomorrow
Hmm, I'll probably do the folder move first
Maybe I misunderstand, but musl
is Zig's default ABI for Linux, so it might be the easiest option:
https://ziglang.org/documentation/0.13.0/std/#std.Target.Abi.default
I'd honestly like to only ever build with musl on Linux
just never deal with libc differences across distros ever again
Anton said:
I'll get started on setting up the CI for the new compiler tomorrow
Can we also include WASM as a build target. So we dont forget about 32-bit arch's.
Jasper Woudenberg said:
Maybe I misunderstand, but
musl
is Zig's default ABI for Linux, so it might be the easiest option:
https://ziglang.org/documentation/0.13.0/std/#std.Target.Abi.default
Oh, missed that....cool. no work. Also, I guess we don't even link libc currently, so no dependency at all even on musl.
Anton said:
I'll get started on setting up the CI for the new compiler tomorrow
Many thanks :folded_hands:. You do the hard work that carries us all.
Jasper Woudenberg said:
Maybe I misunderstand, but
musl
is Zig's default ABI for Linux, so it might be the easiest option:
https://ziglang.org/documentation/0.13.0/std/#std.Target.Abi.default
to be clear, the default is to match the host. If you do not specify a target, and you link libc, it will link against your system libc, whichever one you are running the compiler on. However, if you specify, for example, -target x86_64-linux
then you are cross-compiling, and in this case it picks musl as a default (as well as defaulting to the "baseline" CPU), and a conservative OS version range.
I think it would be great if we could be building on Linux with musl and full static linking as early as possible, and verify it with ci (like, fail ci if any dynamic dependencies are detected in the final output executable)
and I'd like to similarly verify that our only dynamic dep on macOS is libSystem, and on windows that it's whatever the equivalent of libSystem is there. (I think I remember Windows having some dependency you're always expected to link dynamically bc they don't guarantee syscall stability the way Linux does.)
I've got this working on all targets :) PR#7582
Now I just need to integrate this nicely with the current ci-manager workflow
Luke Boswell said:
I wonder if we could use
zig ld
or something like Jakub Konka 'sbold
? these are all written in zig.
Just to clarify, bold is a drop-in replacement for Apple's ld only and missing features :-) https://github.com/kubkon/bold/issues/170
Last updated: Jul 06 2025 at 12:14 UTC