Skip to content

thirdparty: pin AR/RANLIB in autotools foreign builds (fix macOS jemalloc link)#210

Merged
chen3feng merged 1 commit into
masterfrom
thirdparty/pin-foreign-ar-macos
Jun 28, 2026
Merged

thirdparty: pin AR/RANLIB in autotools foreign builds (fix macOS jemalloc link)#210
chen3feng merged 1 commit into
masterfrom
thirdparty/pin-foreign-ar-macos

Conversation

@chen3feng

Copy link
Copy Markdown
Collaborator

Problem

On macOS, blade build //... fails linking je_server:

ld: archive member '/' not a mach-o file in 'build_release/thirdparty/jemalloc/lib/libjemalloc.a'

_configure pins CC/CXX from the resolved toolchain but lets AR/RANLIB fall through to PATH. When a GNU-format ar sits ahead of /usr/bin/ar in PATH (Homebrew binutils, or an llvm-ar invoked in --format=gnu mode), a package built by a direct $(AR) crus Makefile rule produces a GNU-format archive (with / and // index members), which Apple's ld rejects.

Why only jemalloc surfaced it

  • libtool-built archives (libtcmalloc, jsoncpp, ctemplate — _la- object names) drive the archiver consistently → clean __.SYMDEF archives → fine.
  • Direct-$(AR) archives (jemalloc; gperftools' profiler/tcmalloc_and_profiler) pick up the PATH ar → GNU format.
  • Of those, only libjemalloc.a is in the macOS link graph (gperftools' profiler archives are gated Linux-only), so je_server was the only failure.

Verified Apple ld rejects both pure-GNU and GNU+ranlib-mixed archives — the format itself is the issue.

Fix

Pin AR/RANLIB the same way CC/CXX already are: force the system BSD /usr/bin/ar + /usr/bin/ranlib on macOS (they emit a __.SYMDEF archive ld accepts), honor the toolchain ar elsewhere. Passed both as env and as autoconf precious-vars so the generated Makefile uses them.

Covers all autotools_build packages (jemalloc, gperftools, …).

Validation

Clean rebuild on macOS:

  • Makefile now has AR = /usr/bin/ar
  • libjemalloc.a members: __.SYMDEF SORTED + objects (no ///`)
  • je_server links; _je_mallctl resolves

🤖 Generated with Claude Code

…lloc link)

_configure passed CC/CXX from the resolved toolchain but let AR/RANLIB fall
through to PATH. On macOS, a stray GNU-format `ar` ahead of /usr/bin/ar (e.g.
Homebrew binutils / an llvm-ar in --format=gnu mode) builds a package's static
archive in GNU format -- with `/` and `//` index members -- which Apple's ld
rejects at link time:

  ld: archive member '/' not a mach-o file in '.../lib/libjemalloc.a'

This surfaced on je_server (jemalloc's libjemalloc.a is built by a direct
$(AR) crus Makefile rule, so it picks up the PATH ar; libtool-built archives
like libtcmalloc/jsoncpp/ctemplate were unaffected because libtool drives the
archiver consistently). The gperftools profiler archives hit the same GNU
format but are gated Linux-only, so they never reached a macOS link.

Pin AR/RANLIB the same way CC/CXX already are: force the system BSD
ar/ranlib on macOS (they emit a `__.SYMDEF` archive ld accepts), and honor
the toolchain ar elsewhere (GNU archives are fine for GNU ld). Passed both as
env and as autoconf precious-vars so the generated Makefile uses them
(verified: `AR = /usr/bin/ar`, archive members are `__.SYMDEF SORTED` + objects,
je_server links).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@chen3feng chen3feng merged commit 71698ba into master Jun 28, 2026
10 checks passed
@chen3feng chen3feng deleted the thirdparty/pin-foreign-ar-macos branch June 28, 2026 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant