In tpo/applications/tor-browser-build#40139 (closed) we documented that Tor Browser Nightly build for macOS is failing when linking tor using master. This began failing on 24 or 25 October. I haven't bisected which tor commit (or build change) is causing this. Attached is the latest build log when building commit df163760 (tip of master, at build time).
After disabling unittests, the remaining error is:
AR libtor.a /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(protover.o) has no symbols /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(socketpair.o) has no symbols /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(process_win32.o) has no symbols ( cd "/var/tmp/build/tor-6e25c49f7615/src/rust" ; \ CARGO_TARGET_DIR="/var/tmp/build/tor-6e25c49f7615/src/rust/target" \ cargo build --release \ --frozen \ --manifest-path "/var/tmp/build/tor-6e25c49f7615/src/rust/tor_rust/Cargo.toml" ) Compiling libc v0.2.39 Compiling tor_allocate v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_allocate) Compiling smartlist v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/smartlist) Compiling tor_log v0.1.0 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_log) Compiling external v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/external) Compiling tor_util v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_util) Compiling protover v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/protover) Compiling tor_rust v0.1.0 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_rust) Finished release [optimized + debuginfo] target(s) in 0.00s CCLD src/app/tor ld: warning: ignoring file libtor.a, file was built for archive which is not the architecture being linked (x86_64): libtor.a Undefined symbols for architecture x86_64: "_tor_main", referenced from: _main in tor_main.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'll dig into this a bit more later today (and I'll disable compiling rust, so we have fewer variables). The build log shows ranlib from macosx-toolchain is being used, so that leads me to think we don't need to set AR, as well, but I'll report back after I learn more.
After disabling unittests, the remaining error is:
AR libtor.a /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(protover.o) has no symbols /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(socketpair.o) has no symbols /var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin-ranlib: file: library.tmp.a(process_win32.o) has no symbols ( cd "/var/tmp/build/tor-6e25c49f7615/src/rust" ; \ CARGO_TARGET_DIR="/var/tmp/build/tor-6e25c49f7615/src/rust/target" \ cargo build --release \ --frozen \ --manifest-path "/var/tmp/build/tor-6e25c49f7615/src/rust/tor_rust/Cargo.toml" ) Compiling libc v0.2.39 Compiling tor_allocate v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_allocate) Compiling smartlist v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/smartlist) Compiling tor_log v0.1.0 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_log) Compiling external v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/external) Compiling tor_util v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_util) Compiling protover v0.0.1 (/var/tmp/build/tor-6e25c49f7615/src/rust/protover) Compiling tor_rust v0.1.0 (/var/tmp/build/tor-6e25c49f7615/src/rust/tor_rust) Finished release [optimized + debuginfo] target(s) in 0.00s CCLD src/app/tor ld: warning: ignoring file libtor.a, file was built for archive which is not the architecture being linked (x86_64): libtor.a Undefined symbols for architecture x86_64: "_tor_main", referenced from: _main in tor_main.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'll dig into this a bit more later today (and I'll disable compiling rust, so we have fewer variables). The build log shows ranlib from macosx-toolchain is being used, so that leads me to think we don't need to set AR, as well, but I'll report back after I learn more.
Thanks!
That is what git bisect tells us:
e9dbb5e395097f4ae38d17cf27408c2688b90d2b is the first bad commitcommit e9dbb5e395097f4ae38d17cf27408c2688b90d2bAuthor: Nick Mathewson <nickm@torproject.org> Build one big .a library full of Tor's implementation. This is experimental and probably will break some platforms:100644 100644 136368088e1f0b51858775e9e36197de78d34bde50b002139eace5084ed1aed10781da8dc021b0b6 M Makefile.am:040000 040000 6114f76e88580bd772f7f5949a94992620225558654aa8b0255b7beeb6795e79609f055a5c4a119e M scripts:040000 040000 084df3c966695487a231ebc0068c43b40cfafe8556f0284965a852266e4754b4bb6bd02d0098d29e M src
@gk tells me that this is looking like it might be a tor-browser-build issue, and that @sysrqb is looking at it. I'll keep this on my radar; please let me know if you have any questions, or it turns out to be a Tor issue after all.
Georg (rightfully) pushed back a little on my fix for tor-browser-build. I think this should be a tor patch. I opened !200 (merged) with the fix. I also noticed that the recipe for libtor-testing.a already has it, so maybe this was only an oversight.