You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Release builds fail on macOS 27: Rust 1.95 strips proc-macro dylibs with misaligned __LINKEDIT (fixed in Rust 1.98) #8074
On macOS 27, cargo build --release of any crate that uses sqlx macros fails with the pinned Rust 1.95.0 toolchain. The cause is a known LLVM bug that is already fixed in Rust 1.98.0, so bumping rust-toolchain.toml to 1.98 or later resolves it. (#8049 upgrades the Hermit-managed tools but keeps the pin at 1.95.0.)
Reproduction
macOS 27.2 (26B5091g), Xcode 27.0, arm64, at block/buzz main with the pinned toolchain:
$ cargo build --release -p buzz-db
error: …/libsqlx_macros-<hash>.dylib: dlopen(…): … mis-aligned LINKEDIT string pool, fileOffset=0x008730AC
error[E0432]: unresolved imports `self::encode::Encode`, …
error: could not compile `sqlx` (lib) due to 2 previous errors
cargo check and tests pass, because the dev profile doesn't strip. Release builds of buzz-relay and anything else that depends on sqlx macros fail the same way.
Root cause
Cargo's release profile defaults to strip = "debuginfo". On macOS, rustc strips with its bundled rust-objcopy (LLVM), not Apple's strip.
LLVM's Mach-O objcopy wrote __LINKEDIT entries at offsets that are only 4-byte aligned, which macOS 27's dyld now rejects.
Small proc-macro dylibs often pass by luck of alignment, which is why a trivial repro may not trigger it. The sqlx-macros dylib Buzz builds (~12 MB, with Buzz's sqlx features) triggers it reliably.
Suggested fix
Bump rust-toolchain.toml to 1.98.0 or later (current stable is 1.99.0).
Until then, this workaround disables stripping only for build-time artifacts (proc macros, build scripts) and leaves shipped binaries unchanged:
Activity
chore(toolchain): bump Rust to 1.98.1 for macOS 27 proc-macro loading (…