wrk2 installation failed on Mac OS Monterey and Apple M1 Max chip

[srikanth-bathineni]

I am using below commands to install wrk2 and facing error

brew tap jabley/homebrew-wrk2
brew install --HEAD wrk2

#error "Need at least GCC 4.3 or newer"
^
3 errors generated.
lj_arch.h:55:2: error: "No support for this architecture (yet)"
#error "No support for this architecture (yet)"
^
lj_arch.h:279:2: error: "No target architecture defined"
#error "No target architecture defined"
^
lj_arch.h:302:2: error: "Need at least GCC 4.3 or newer"
#error "Need at least GCC 4.3 or newer"
^
3 errors generated.
Makefile:231: *** Unsupported target architecture. Stop.
make: *** [deps/luajit/src/libluajit.a] Error 2

[orefalo]

same issue

[orefalo]

found this guy https://github.com/AppsFlyer/wrk3

[galderz]

Somehow ended up in this issue, but didn't see the PR that had already been opened to fix this: #110. So, without being aware of that I came up with my own PR haha: #128 - Anyway....

[jaynguyen-vn]

🤖 This response was generated by AI and may contain inaccuracies. Please verify before acting on it.

Root Cause Analysis — wrk2 build fails on Apple Silicon (M1 Max)

Verified diagnosis

The failure is not a compiler/Homebrew problem on your machine. It is that wrk2 vendors an obsolete LuaJIT that predates Apple Silicon.

• deps/luajit/ is imported source (not a submodule), and the only commit that created it is: import LuaJIT 2.0.3 (2014-05-15). So wrk2 ships LuaJIT 2.0.3 from 2014.
• In deps/luajit/src/lj_arch.h the architecture-detection block recognizes only __i386, __x86_64__, __arm__ (32-bit ARM), __ppc*, and __mips*. There is no __aarch64__ / arm64 branch anywhere in the vendored LuaJIT source.
• Your M1 Max compiles as arm64 (aarch64). None of the recognized macros match, so:
  1. lj_arch.h:55 "No support for this architecture (yet)" — LUAJIT_TARGET never gets defined.
  2. lj_arch.h:279 "No target architecture defined" — cascades from README: Adjust formatting #1.
  3. lj_arch.h:302 "Need at least GCC 4.3 or newer" — cascades again (with no target macro set, the generic GCC-version guard fires).
  4. Makefile:231 *** Unsupported target architecture — LuaJIT's own Makefile aborts.

All four errors are the same root cause: arm64 is unknown to LuaJIT 2.0.3. Native arm64 (aarch64) support only landed in the LuaJIT 2.1 branch. Note: brew install --HEAD wrk2 via the third-party jabley/homebrew-wrk2 tap just builds this repo's master from source, so it inherits this exact limitation.

Options

A. Immediate workaround (no repo change) — build under Rosetta 2 / x86_64
Force an x86_64 toolchain so LuaJIT detects the supported x64 target:

# x86_64 Homebrew openssl needed for the x64 build
arch -x86_64 /bin/bash
make CFLAGS="-I/usr/local/opt/openssl/include" LDFLAGS="-L/usr/local/opt/openssl/lib"

• Pros: unblocks you today; zero maintainer action.
• Cons: emulated, not native arm64 performance; needs an x86_64 brew/openssl; benchmarking tool running under emulation skews results.

B. Permanent repo fix — upgrade vendored LuaJIT to the 2.1 branch (recommended)
Replace deps/luajit/ with LuaJIT v2.1 (official v2.1 branch or OpenResty's luajit2), which has native macOS arm64 support.

• Pros: fixes root cause for all Apple Silicon users; also benefits x64; native performance.
• Cons: larger diff; must re-verify the luajit -b bytecode step (obj/bytecode.o), and revisit the macOS LDFLAGS -pagezero_size 10000 -image_base 100000000 (an x64-only LuaJIT 2.0 hack; LuaJIT 2.1's GC64 mode makes it unnecessary on 64-bit).

C. Link against system/Homebrew LuaJIT instead of vendoring
brew install luajit (2.1) and point the Makefile's LDIR/-lluajit at it.

• Pros: smallest ongoing maintenance.
• Cons: changes build assumptions; requires luajit installed; loses pinned/reproducible version; the bytecode step still needs a luajit binary present.

Recommendation

For the reporter: use Option A (Rosetta/x86_64) to unblock now. For the project: Option B (bump vendored LuaJIT to 2.1) is the durable fix; the design decision is mainly which 2.1 source to vendor and whether to drop the x64-only LDFLAGS on arm64.

Questions

1. Do you want a permanent repo fix (upgrade vendored LuaJIT to 2.1), or just document the Rosetta workaround in the README for now?
2. If upgrading: prefer the official LuaJIT v2.1 branch, or OpenResty's luajit2 fork (more actively patched)?
3. Keep vendoring LuaJIT in deps/luajit/, or switch the Makefile to link the system/Homebrew LuaJIT?
4. On arm64, should we drop the x64-only -pagezero_size/-image_base LDFLAGS (GC64 makes them moot), or keep them for x64 only via a target conditional?
5. Is fixing the third-party Homebrew tap (jabley/homebrew-wrk2) in scope, or only the repo's make build path?

---

Powered by ClaudeKit

[orefalo]

I switched to oha, works no problems

[jaynguyen-vn]

🤖 This response was generated by AI and may contain inaccuracies. Please verify before acting on it.

Updated analysis — reporter switched to oha

Thanks for the update. Switching to oha is a reasonable unblock: it's a Rust HTTP load tester with a constant-throughput (RPS) mode similar in spirit to wrk2's coordinated-omission-free design, and it ships native Apple Silicon (arm64) binaries — so it sidesteps the exact problem here.

What this changes

• For you (the reporter): issue is resolved on your end — no action needed.
• For the repo: the root cause is unchanged and still open. The build failure was never about your machine, Homebrew, or the compiler. wrk2 vendors LuaJIT 2.0.3 (2014) in deps/luajit/, and that version's lj_arch.h has no __aarch64__/arm64 branch. Every Apple Silicon user hits the same cascade (No support for this architecture, No target architecture defined, Need at least GCC 4.3, Unsupported target architecture). Native arm64 only exists in the LuaJIT 2.1 branch.

So your workaround (use a different tool) is valid, but it does not resolve the underlying repo defect — anyone on M1/M2/M3 who actually needs wrk2 (not oha) will still fail to build.

Where this leaves the issue

Two independent tracks:

1. Reporter unblocked ✅ via oha.
2. Repo fix still pending ⏳ — requires a maintainer decision, since it's a vendored-dependency upgrade with build-system implications (which LuaJIT 2.1 source, vendor vs. link system luajit, and whether to drop the x64-only -pagezero_size/-image_base LDFLAGS under GC64).

The new comment is helpful context but doesn't answer any of the design questions, so I can't lock an implementation plan yet — the choice of whether and how to fix is a project decision, not something the reporter's tool-switch settles.

---

Powered by ClaudeKit