Getting the Zig port working again

Software Ports
1

A while ago, Zig had an experimental port to Haiku c. version 0.8.0. Unfortunately, this support has bit-rotted over time due to the mass amounts of internal changes since then. Right now I’m trying to get the port going again, but I’m running into some roadblocks that are halting my progress.

Right now I’m following these [1][2] two guides that explain how to build LLVM (currently 16.x) and Zig from source. At a high level, Zig is built by:

  1. Compiling a simple WASM vm to convert a stripped-down WASM version of the Zig compiler to C (stage 1).
  2. Compile the C conversion as a native binary (stage 2).
  3. Use the native binary to compile Zig again (stage 3).

The problem I’m facing is in step 3. To build any Zig project, Zig will compile a build runner program and use that to compile any source files. When building stage 3, this build runner fails due to an index oob error.

[9/9] Building stage3
FAILED: stage3/bin/zig /boot/home/gits/zig/build/stage3/bin/zig
cd /boot/home/gits/zig && /boot/home/gits/zig/build/zig2 build --prefix /boot/home/gits/zig/build/stage3 --zig-lib-dir /boot/home/gits/zig/lib -Dconfig_h=/boot/home/gits/zig/build/config.h -Denable-llvm -Doptimize=ReleaseFast -Dtarget=native -Dcpu=native -Dversion-string=0.11.0-dev.2893+e963793e3
thread 1067 panic: index out of bounds: index 43690, len 1024
Panicked during a panic. Aborting.
Abort
error: the following build command crashed:
/boot/home/gits/zig/zig-cache/o/990e1c20ca3201c45788a875af4f27b7/build /boot/home/gits/zig/build/zig2 /boot/home/gits/zig /boot/home/gits/zig/zig-cache /boot/home/config/cache/zig --prefix /boot/home/gits/zig/build/stage3 --zig-lib-dir /boot/home/gits/zig/lib -Dconfig_h=/boot/home/gits/zig/build/config.h -Denable-llvm -Doptimize=ReleaseFast -Dtarget=native -Dcpu=native -Dversion-string=0.11.0-dev.2893+e963793e3
ninja: build stopped: subcommand failed.

The index number is a tell, since it’s 0xaaaa - the default for undefined variables in Debug mode Zig. Unfortunately I cannot find where in the code this is tripping, as the port doesn’t support backtraces and neither the native debugger nor GDB from haikuports can load the file with source file info.

So, I’m posting here to request the help of some Haiku experts to get this port going again. To start, compiling and file access is pretty slow in my QEMU/KVM vm and making this faster would go a long way in shortening my build+debug cycle.

3 Likes
2

one possible way to debug this would to git bisect this, I’m not sure if this would work in this case that well though : )

3

hello,

it’s good to hear someone willing to take the torch for continuing the port of zig on haiku.

as i was the person that had started the initial porting effort of zig to haiku, perhaps some of my commentary can help point you in a direction to move the port further along. i’m afraid these days i don’t have the time or personal bandwidth to continue efforts on the haiku port for zig so will not be able to answer any follow up questions that might/will crop up for the foreseeable future.

i have never been able to complete the stage3 build of zig on haiku reliably, even in the 0.8.x releases. but the fact you are still able to build stage2 is a good sign. that was one of the earlier goals i had set out to improve (ensure stage2 could at least build on haiku). if you did not have to patch your checkout to build stage2 then at least that section has not suffered from too much bit-rot.

here are some challenges that i had encountered when i was working on this port. hopefully they are less of a problem now:

  • zig releases (and mainline) moved at a pretty fast pace (at least when i was working on this) and one of the things that kept coming back was the need to keep compiling and upgrading the whole llvm toolchain in order to keep track of zig changes
  • the llvm toolchain for haiku needed patches itself just to be able to build (couldn’t use ready made haikuport)
  • as you’ve found out, the lack of being able to use zig’s debugging abilities on haiku made problems like the one you are seeing more difficult (strace might give some insights)

here’s an unsorted (wish)list of things/observations that i think would be good to have / explore in getting the zig port for haiku further.

  • debugging working for zig. there should be stub hooks in place for haiku (check in lib/std/debug.zig might help) that could use some care
  • checking that the threading support for zig maps well to current abstractions offered by haiku
  • have readily available llvm toolchain haikuports that can work with latest zig (moving target), having to compile the whole toolchain just to work on zig is definitely a timesink
  • ensure haiku syscall-related (in either lib/std/os or lib/std/c) are in sync with haiku’s current system calls (shouldn’t have changed too much, i think)
  • get stage3 builds to consistently build on haiku
  • be able to build from the zig-bootstrap repo (most likely will require patches to compiler toolchains as well as zig itself). one approach might be to keep an updated fork with all patches applied
  • fix the default included linked libraries when building zig. last i checked, -lnetwork and -lbsd needed to be manually included into zig projects rather than be included by default which ended up manifesting itself in lots of link error issues. i think it would be a good thing to have this included by default when building for haiku
  • take advantage of dl_iterate_phdr support for more recent haiku builds in zig (wasn’t available when i started)
  • see if zig project is open to backporting any improvements made to haiku on earlier release branches
  • compiling stage2 was rather memory intensive (i found it easier if i didn’t try to compile it on a machine with 4Gb or less memory but ymmv)

hope these rambling thoughts might have something of interest and i wish you luck in your efforts on geting this port in a better state!

6 Likes