Stream: compiler development

Topic: zig compiler - surgical linker


view this post on Zulip Jakub Konka (Mar 02 2025 at 16:12):

Hey y'all! Been a bit preoccupied with other stuff lately. I have a q or two regarding the rewrite in Zig: is the surgical linker rewrite on the roadmap too? Trying to judge the landscape before committing to potentially pointlessly advancing Rust implementation if it's gonna get rewritten in Zig anyhow. FWIW getting the surgical linker on macOS working in Zig should be much simpler (famous last words) ;-)

view this post on Zulip Brendan Hansknecht (Mar 02 2025 at 18:17):

So the hope is that the surgical linker will be fully removed from the critical path for a good experience with Roc. As such, it becomes optional to port. Instead, the default Roc flow will use an interpretter (no object files or linking except for a small shim shared library to force a platform to launch the interpretter). The shim only has to built on first run of the platform, so linking costs don't really matter. After that, the interpretter gives a fast dev feedback loop. There will still be an optimized roc flow using llvm. Given this flow will be much rarer to run and waiting on llvm anyway, it is not too important for it to have fast link times.

With the rewrite plans, we essentially are nixing the need for dev backends and the surgical linker. :fingers_crossed: the interpretter works as good as we hope for dev builds.

view this post on Zulip Jakub Konka (Mar 02 2025 at 19:17):

Oh wow, that sounds great actually! Less complexity is always welcome!

view this post on Zulip Jakub Konka (Mar 02 2025 at 19:23):

So let me try and understand the new approach a little bit more. Who's defining the shim?

view this post on Zulip Brendan Hansknecht (Mar 02 2025 at 19:55):

Yeah, so the idea is that we still fit into the same box that we would setup for llvm. So the platform is calling a function with cffi that has know types for every arg and the return type.

The shim, is just a function that goes from that representation to a tagged representation for the interpretter. It will then call the interpretter (which will just be a shared library with a c abi where everything is tagged).


The shim is essentially platform specific. The platform already knows the exact abi it expects roc to fit into. My looking at the entry point roc functions, we can build the shim. I assume we would create it right after downloading a platform (though I guess we could actually include it as part of the platform packaging step).

view this post on Zulip Brendan Hansknecht (Mar 02 2025 at 19:58):

I still have to fully think about the details of the linking story. I think in the perfect world, a platform would be a static library that contains a main function and every dependency (or instructions to get dependencies and required linker flags). Roc would really just be running the linking command specified by the platform with either a shim object file or a fully optimized llvm object file.

view this post on Zulip Luke Boswell (Mar 02 2025 at 20:02):

Also this might help https://github.com/lukewilliamboswell/roc-platform-template-zig/tree/calling-roc

view this post on Zulip Luke Boswell (Mar 02 2025 at 20:02):

Brendan and I spent some time exploring ideas for the new way we are planning for calling roc.


Last updated: Jul 06 2025 at 12:14 UTC