+ziglang.org

[jhheider]

doesn't currently build on linux/x86-64:gha:debian:buster-slim due to OOM. The Zig team is well aware that their build process is memory-heavy: ziglang/zig#6485

[what-the-diff]

• The build.zig file was modified to include the headerpad_max_install_names option
• A package yml file was added for ziglang/zig, which includes a patch that applies the same change as in 1 above

[mxcl]

We need self-hosted x86 clearly

[jhheider]

@mxcl do you have any familiarity with this: https://github.com/teaxyz/pantry.extra/actions/runs/3935162447/jobs/6730616244

+ codesign -v --sign - --force --preserve-metadata=entitlements,requirements,flags,runtime /opt/ziglang.org/v0.10.0/bin/zig
/Library/Developer/CommandLineTools/usr/bin/codesign_allocate: fatal error: file not in an order that can be processed (function starts data out of place): /opt/ziglang.org/v0.10.0/bin/zig
/opt/ziglang.org/v0.10.0/bin/zig: the codesign_allocate helper tool cannot be found or used

Only occurs on darwin/x86-64 (I'm manually running codesign to see the actual error, since ruby-machos doesn't pass it out).

[mxcl]

who's doing the code signing? (looks like zig is, but not sure since the + prefixes suggest we might be).

If us, can we skip it?

[jhheider]

who's doing the code signing? (looks like zig is, but not sure since the + prefixes suggest we might be).

If us, can we skip it?

It's us in fix-machos.rb. I added a manual invocation using the same command line to see what the actual error is. I think we'd need to make a specific exemption in fix-machos.rb, but that's not impossible.

[mxcl]

maybe this brew patch? https://github.com/Homebrew/homebrew-core/blob/master/Formula/zig.rb#L80

headerpad is a thing that code signing needs sometimes.

[jhheider]

Already present. ziglang/zig#9565 is interesting, but doesn't make me closer to understanding.

[jhheider]

otool outputs, in case that helps anyone: https://gist.github.com/jhheider/ab79a6b55fae8231b734188a789684cc

[lino-levan]

Given that tea now allows packages that only build on Mac OS, is there anything that could be done to push this forward?

[jhheider]

A better solution is probably to what Max originally suggested and use vendored packages, a la https://github.com/teaxyz/pantry.extra/blob/main/projects/bun.sh/package.yml. I'll see if I can't whip that up.

[jhheider]

closes #609

[jhheider]

for you, @lino-levan

[lino-levan]

Thanks!