Emi

Wow, nice! That bitcast warning is interesting ... so the reason the bitcast is there is because we have _the same exact code_ symlink'd into the `libs/` directory (so `$REPO/gpu/libs/mach-glfw`...

@PiergiorgioZagaria nice work, thanks so much for continuing to dig into this. I updated the issue description just now with what (I think?) the status quo is w.r.t. stage2 support,...

aarch64-macos now mostly working. ## Workarounds employed: * Our `map-async` example (which does not use zig async) required adding a useless field to the `App` file struct (`*App` is treated...

apple_pie has since been replaced with a web server dedicated to WASM serving: https://github.com/hexops/mach/tree/main/tools/wasmserve We're now fully on the self-hosted compiler, so closing.

I agree `MACH_PLATFORM` should be the env var name, and `GPU_BACKEND` renamed to `MACH_GPU_BACKEND`. @PiergiorgioZagaria If you use GLFW, you would pass the option to GLFW via `glfw.Init(.{.platform = .wayland})`...

> the sponsor link from the website 404s Thank you so much for mentioning that! I totally missed that. I'll fix soon. > Should zig build check for this version?...

Thanks for filing this, and for reaching out earlier about the same issue @Luexa ! I removed the unused static libraries from `mach/gpu/build.zig` and `mach/build.zig` in #220 > the `LibExeObjStep`...

Should be fixed now, see https://github.com/hexops/mach/commit/eb0eceb707b3ead72599bcd5dff432c55ccf7740 for details. Note that https://github.com/hexops/mach/issues/444 is still an issue, however.

@cocoademon I'm pretty sure this is the issue you're running into, in the FAQ: https://github.com/hexops/mach/blob/main/doc/known-issues.md#windows-file-not-found I am hoping to eventually eliminate all symlinks from the codebase to avoid this issue...

OK, makes sense, thanks for reporting this. I do think we could solve this with `std.os.realpath` - but for me this just reiterates, again, how bad/annoying symlinks are to deal...