feat: add aarch for ios arm - #5
Open
pollend wants to merge 3 commits into
Open
Conversation
pollend
force-pushed
the
feature/add-support-for-osx
branch
from
January 22, 2026 05:59
ca28327 to
549caf8
Compare
Signed-off-by: Michael Pollind <mpollind@gmail.com>
pollend
force-pushed
the
feature/add-support-for-osx
branch
from
January 22, 2026 06:30
549caf8 to
daeee6d
Compare
pollend
marked this pull request as ready for review
January 22, 2026 06:36
pollend
marked this pull request as draft
January 22, 2026 07:11
pollend
marked this pull request as ready for review
January 24, 2026 03:08
agagniere
reviewed
Apr 17, 2026
|
|
||
| // Using the package manager, this artifact can be obtained by the user | ||
| // through `b.dependency(<name in build.zig.zon>, .{}).artifact("vulkan-zig-generator")`. | ||
| // with that, the user need only `.addArg("path/to/vk.xml")`, and then obtain |
Member
There was a problem hiding this comment.
Looks like copy-pasted comment you forgot to remove ?
Signed-off-by: Michael Pollind <mpollind@gmail.com>
agagniere
approved these changes
Jul 4, 2026
This was referenced Aug 23, 2026
floatdrop
added a commit
to zoxy-io/zrk
that referenced
this pull request
Aug 23, 2026
zrk and zoxy both terminate or originate TLS through ztls, and until now they did it on different primitives: zrk on a Zig-built BoringSSL, zoxy on whatever libcrypto the build machine's nix store happened to hold. One pin now serves both. It had to be OpenSSL rather than BoringSSL, and not for zrk's sake. The BoringSSL family has no `CRYPTO_set_mem_functions`, so zoxy's fixed libcrypto heap cannot install and `main.zig` refuses to start rather than run without its zero-allocation budget. BoringSSL works fine here — zrk installs no allocation hooks — so this change buys zrk nothing except not being the odd one out. That is the whole reason for it: two programs, one libcrypto, one set of CVEs to track, one thing to audit. The fork is zoxy-io/openssl, carrying allyourcodebase/openssl#5 — pre-generated perlasm for aarch64, which upstream has only for x86_64 — on top of a bump from 3.3.2 (September 2024) to 3.5.7, the LTS line supported to April 2030. The mechanics get simpler, not harder. BoringSSL needed two archives, because it splits the primitives into a `bcm` that declares no dependency on `crypto` and omitting it left 236 undefined `BN_*` symbols; OpenSSL is one. The explicit include path on ztls's module is gone too — the package installs its headers, so `linkLibrary` carries them. What remains is an alias: ztls asks the linker for `-lcrypto` by name and this package emits `libopenssl.a`, so a copy is published under the name the linker looks for. Verified locally, which was not possible before: BoringSSL could never fetch in this sandbox, so every crypto change until now was validated only in CI. `zig build test` green, `zrk --version` runs, and all four release targets cross-compile — x86_64 and aarch64, Linux and macOS. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
floatdrop
added a commit
to zoxy-io/zoxy
that referenced
this pull request
Aug 23, 2026
`linkSystemLibrary("crypto")` resolved libcrypto out of the *build machine's*
nix store, and that one line is why this repository builds the way it does.
Every target but the host's own failed to link, so release.yml builds natively
on one runner per target; x86_64-macos has been absent since 0.2.0 for want of
an Intel runner; and the release has to resolve `nixpkgs#pkgsStatic.openssl`
and thread PKG_CONFIG_PATH through `devenv shell -- env` to avoid shipping a
binary that wants a musl-ABI libcrypto.so.3 it cannot find.
Linking a Zig-built artifact removes the premise. libcrypto is now built for
the target, statically, on every build — dev, CI and release alike.
OpenSSL, not BoringSSL. zoxy-io/zrk took the BoringSSL route for the same
problem, and it is not available here: the BoringSSL family has no
`CRYPTO_set_mem_functions`, so `tls/libcrypto_heap.zig`'s `install` returns
false and `main.zig` refuses to start rather than run without §5's
zero-allocation budget. The fork carries allyourcodebase/openssl#5 —
pre-generated perlasm for aarch64 — on top of a 3.3.2 -> 3.5.7 bump onto the
LTS line. zrk moves to the same pin, so both programs sit on one libcrypto.
Three details the diff does not explain itself:
- The ztls pin has to move. 634567a predates `-Dcrypto-pkg-config`, and
without it pkg-config injects the system OpenSSL's include path ahead of
ours and the C import dies on typedef collisions — but only where
pkg-config knows about OpenSSL, so it would pass CI and break on a laptop.
03c2464 is build plumbing only; `src/` is byte-identical, so the audited
crypto surface does not move. Re-audit note is in build.zig.zon.
- Two libcryptos, because the ReleaseSafe twin builds its own ztls at a
different optimize mode and the archive has to match it.
- ztls asks the linker for `-lcrypto` by name and this package emits
`libopenssl.a`. Linking the artifact resolves every symbol, but the linker
must still find a file of that name first, so a copy is published under it
and the search path points there.
Verified: `zig build ci` green — 4096 simulation seeds, smoke clean, counters
reconcile. `zig build tls-heap-proof` passes, which is the load-bearing one: a
real handshake ran entirely on the fixed heap, so `CRYPTO_set_mem_functions`
installed and libcrypto's allocations landed in memory we own. `otool -L` on
the binary shows libSystem and nothing else — zero nix-store references, now
by construction rather than by aiming pkg-config at pkgsStatic.
release.yml is untouched here. Its PKG_CONFIG_PATH machinery is now inert
rather than wrong, and taking the native matrix apart — and adding back
x86_64-macos — is its own change.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
So I tried a couple different things I think this is a sensible way to handle this. The zig code is so this can be updated when openssl updates. should be somewhat easy to just update openssl generate the new asm and just verify what has changed. not sure about other platforms and architectures but that should be somewhat easy to update and generate the new assembly code.