MacOS + GCC11: `LIBS` build error (Undefined symbol `___atomic_compare_exchange_16`)

[evanmiller]

Getting closer but the following error appears with GCC 11 / Mac OS X 10.6:

(2/26) BUILDING cmake v0.1.38
> bin/mrustc rustc-1.39.0-src/vendor/cmake/src/lib.rs -o output-1.39.0/libcmake-0_1_38.rlib --crate-name cmake --crate-type rlib -C emit-depfile=output-1.39.0/libcmake-0_1_38.rlib.d --crate-tag 0_1_38 -g --cfg debug_assertions -O -L output-1.39.0 --extern cc=output-1.39.0/libcc-1_0_35.rlib
> bin/mrustc rustc-1.39.0-src/vendor/libc/build.rs --crate-name build --crate-type bin -o output-1.39.0/build_libc-0_2_62_Hd_run -L output-1.39.0 -g --cfg feature=rustc-dep-of-std --cfg feature=align --cfg feature=rustc-std-workspace-core
Undefined symbols for architecture x86_64:
  "___atomic_compare_exchange_16", referenced from:
      _ZRG4cE9core0_0_09core_arch6x86_6410cmpxchg16b_D0g in libcore.rlib.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

Maybe mrustc needs to add another GCC flag or libatomic linkage?

[bjorn3]

This should use the cmpxchg16b instruction. Does passing -mcpu=core2 to gcc work? That is what rustc passes to llvm on macOS. https://github.com/rust-lang/rust/blob/f1ce0e6a00593493a12e0e3662119786c761f375/compiler/rustc_target/src/spec/x86_64_apple_darwin.rs#L6

[evanmiller]

-mcpu=core2 works on a small test program.

[thepowersgang]

Was the first intel mac a core2? If it was, then maybe that flag could be included by default in the target's compiler options (see src/trans/target.cpp)

[evanmiller]

The very first Intel Macs were 32-bit "Core Solo" and "Core Duo". Poking around EveryMac, it appears that the first 64-bit Macs were in fact core2. So I think it's safe to add to the x86_64 target.

[evanmiller]

This error still appears when attempting to compile with GCC 11 / 10.6.8 / x86_64.

[thepowersgang]

With the above PR applied? can you confirm that -march is being passed?

[evanmiller]

With the PR applied, though it fails at a different step (compiling cc instead of cmake).

I will build again and see if I can provide more context.

[evanmiller]

:info:build (0/20) BUILDING cc v1.0.68
:info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/mrustc-15a5cb1f066bd148bd2959c63adb649e7a06e5ce/bin/mrustc rustc-1.54.0-src/vendor/cc/src/lib.rs -o output-1.54.0/libcc-1_0_68.rlib --crate-name cc --crate-type rlib -C emit-depfile=output-1.54.0/libcc-1_0_68.rlib.d --crate-tag 1_0_68 -g --cfg debug_assertions -O -L output-1.54.0 --edition 2018
:info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/mrustc-15a5cb1f066bd148bd2959c63adb649e7a06e5ce/bin/mrustc rustc-1.54.0-src/vendor/libc/build.rs --crate-name build --crate-type bin -o output-1.54.0/build_libc-0_2_95_H19_run -L output-1.54.0 -g --cfg feature=rustc-dep-of-std --cfg feature=align --cfg feature=rustc-std-workspace-core
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/.tmp/ccnsvyFA.s:78:11: warning: section "__datacoal_nt" is deprecated
:info:build         .section __DATA,__datacoal_nt,coalesced
:info:build                  ^      ~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/.tmp/ccnsvyFA.s:78:11: note: change section name to "__data"
:info:build         .section __DATA,__datacoal_nt,coalesced
:info:build                  ^      ~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/.tmp/ccnsvyFA.s:277:11: warning: section "__datacoal_nt" is deprecated
:info:build         .section __DATA,__datacoal_nt,coalesced
:info:build                  ^      ~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_mrustc/mrustc/work/.tmp/ccnsvyFA.s:277:11: note: change section name to "__data"
:info:build         .section __DATA,__datacoal_nt,coalesced
:info:build                  ^      ~~~~~~~~~~~~~
:info:build Undefined symbols for architecture x86_64:
:info:build   "___atomic_compare_exchange_16", referenced from:
:info:build       _ZRG4cE9core0_0_09core_arch6x86_6410cmpxchg16b_D0g in libcore.rlib.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status
:info:build C Compiler failed to execute - error code 256

Is there an easy way to see the compiler invocation?

[thepowersgang]

The _cmd.txt files in the build directories contain the C compiler arguments (the actual command run is in the _dbg.txt file)

[evanmiller]

-march=core2 is being passed.

[thepowersgang]

I don't have a mac on which to test, nor do I have experience with them. Anyone else able to determine the cause and a suitable fix?

[evanmiller]

Relevant? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878

[thepowersgang]

That seems to imply that -latomic will solve the problem, can you try adding that to the linker options?

[evanmiller]

Adding -latomic in src/trans/target.cpp indeed fixes the issue.

[evanmiller]

In that case the -march flags may be unnecessary but I will need to recompile to verify.

[evanmiller]

Builds and tests OK with -latomic and without the -march=core2 flag. It's possible the latter flag is implicit when GCC is compiling on x86_64 / Darwin.

[thepowersgang]

Are you good to make a PR with that change? (could also try adding macos to the github actions while you're there)

[evanmiller]

Sure. Are we OK passing -latomic to clang? Keep or chuck the -march flags?

[thepowersgang]

Really, whatever works :)

[catap]

@evanmiller I doubt that -latomic makes any harm on clang ;)

[evanmiller]

@catap I think libatomic only ships with GCC. On a stock system running clang I get ld: library not found for -latomic. So we'll need to find a branch point for linking it with GCC but not Clang.

[catap]

@evanmiller indeed.

Anyway, I'd love to point here one more gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649

[catap]

Just tested with GCC 12.1.0 => an issue still here :(

[catap]

This is clear a bug inside GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

I not sure how to fix it, because clang hasn't got -latomic which is default compiler on modern macOS.

[catap]

Just for records. An easy hack to make gcc works very well is adding cargo:rustc-link-lib=atomic to script-overrides/stable-1.54.0-macos/build_libc.txt