Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
evanmiller opened this issue Jan 6, 2022 · 25 comments · Fixed by #245
Open

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

evanmiller opened this issue Jan 6, 2022 · 25 comments · Fixed by #245
Labels
I-ccompiler A bug in the downstream C compiler

Comments

@evanmiller
Copy link
Contributor

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?
@evanmiller evanmiller changed the title Build error with GCC 11 (Undefined symbol ___atomic_compare_exchange_16) LIBS build error with GCC 11 (Undefined symbol ___atomic_compare_exchange_16) Jan 6, 2022
@bjorn3
Copy link
Contributor

bjorn3 commented Jan 6, 2022

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
Copy link
Contributor Author

-mcpu=core2 works on a small test program.

@evanmiller evanmiller mentioned this issue Jan 11, 2022
Merged
11 tasks
@thepowersgang
Copy link
Owner

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
Copy link
Contributor Author

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.

catap added a commit to catap/mrustc that referenced this issue Feb 8, 2022
@catap
Enforce -mtune=core2 and -mtune=yonah on macOS
4f13099 
I've used the same cpu which is used by Rust: `core2` for x86_64[1] and
`yonah` for i686[2]. I also used `mtine` instead of `mcpu` because it
was deprecated at gcc since version 5[3].

It closes thepowersgang#214

I also added missed `i686-apple-darwin` target.

Footnotes:
[1]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/x86_64_apple_darwin.rs
[2]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/i686_apple_darwin.rs
[3]  gcc-mirror/gcc@9d913bb
@catap catap mentioned this issue Feb 8, 2022
Merged
catap added a commit to catap/mrustc that referenced this issue Feb 9, 2022
@catap
Enforce -march=core2 and -march=yonah on macOS
fe6dbef 
I've used the same cpu which is used by Rust: `core2` for x86_64[1] and
`yonah` for i686[2]. I also used `mtine` instead of `mcpu` because it
was deprecated at gcc since version 5[3].

It closes thepowersgang#214

I also added missed `i686-apple-darwin` target.

Footnotes:
[1]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/x86_64_apple_darwin.rs
[2]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/i686_apple_darwin.rs
[3]  gcc-mirror/gcc@9d913bb
thepowersgang pushed a commit that referenced this issue Feb 9, 2022
@catap @thepowersgang
Enforce -march=core2 and -march=yonah on macOS
94ffdd3 
I've used the same cpu which is used by Rust: `core2` for x86_64[1] and
`yonah` for i686[2]. I also used `mtine` instead of `mcpu` because it
was deprecated at gcc since version 5[3].

It closes #214

I also added missed `i686-apple-darwin` target.

Footnotes:
[1]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/x86_64_apple_darwin.rs
[2]  https://github.com/rust-lang/rust/blob/1.54.0/compiler/rustc_target/src/spec/i686_apple_darwin.rs
[3]  gcc-mirror/gcc@9d913bb
@evanmiller
Copy link
Contributor Author

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

@thepowersgang
Copy link
Owner

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

@thepowersgang thepowersgang reopened this Feb 13, 2022
@evanmiller
Copy link
Contributor Author

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
Copy link
Contributor Author 

: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
Copy link
Owner

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

@evanmiller
Copy link
Contributor Author

-march=core2 is being passed.

@thepowersgang
Copy link
Owner

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
Copy link
Contributor Author

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

@thepowersgang
Copy link
Owner

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

@evanmiller
Copy link
Contributor Author

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

@evanmiller
Copy link
Contributor Author

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

@evanmiller
Copy link
Contributor Author

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
Copy link
Owner

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

@evanmiller
Copy link
Contributor Author

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

@thepowersgang
Copy link
Owner

Really, whatever works :)

@catap
Copy link
Contributor

catap commented Feb 13, 2022

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

@evanmiller
Copy link
Contributor Author

@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
Copy link
Contributor

catap commented Feb 13, 2022

@evanmiller indeed.

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

@thepowersgang thepowersgang changed the title LIBS build error with GCC 11 (Undefined symbol ___atomic_compare_exchange_16) MacOS + GCC11: LIBS build error (Undefined symbol ___atomic_compare_exchange_16) Feb 28, 2022
@thepowersgang thepowersgang added the I-ccompiler A bug in the downstream C compiler label Jun 25, 2022
@catap
Copy link
Contributor

catap commented Aug 6, 2022

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

catap added a commit to catap/mrustc that referenced this issue Aug 10, 2022
@catap
Introducing MRUSTC_LIB env variable (ref thepowersgang#214)
d5185cc 
The idea is simple: we need some way to put `-latomic` to `gcc` call.
Let add a dedicated variable which allows to add any library which may
be needed.
@catap catap mentioned this issue Aug 11, 2022
Closed
catap added a commit to catap/mrustc that referenced this issue Aug 11, 2022
@catap
Introducing MRUSTC_LIB env variable
615ab60 
The idea is simple: we need some way to put `-latomic` to `gcc` call.
Let add a dedicated variable which allows to add any library which may
be needed.

It may fixes: thepowersgang#214
@catap
Copy link
Contributor

catap commented Sep 3, 2022 •
edited
Loading

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
Copy link
Contributor

catap commented Sep 3, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-ccompiler A bug in the downstream C compiler
Projects
None yet
Milestone
No milestone
4 participants
@catap @evanmiller @thepowersgang @bjorn3