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.

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

Link error on macOS with GCC 9 #119

Open
SimplyTheOther opened this issue Jul 19, 2019 · 1 comment
Open

Link error on macOS with GCC 9 #119

SimplyTheOther opened this issue Jul 19, 2019 · 1 comment
Labels
stale No response received after potential fixes.

Comments

@SimplyTheOther
Copy link

SimplyTheOther commented Jul 19, 2019

This may or may not be the same as the other "linker issue" mentioned in other issues, so I have opened a separate one.

Trying to build: rustc libraries and rustc
Host system version: macOS Mojave 10.14.5, x86_64-apple-darwin18.6.0
Compiler: GCC 9.1.0 (Homebrew GCC 9.1.0), target x86_64-apple-darwin18
mrustc version: latest commit (ebd8ede)

Note that I also changed the rustc default target to "x86_64-apple-darwin", as per recommended for non-Linux systems.

Judging by terminal output, mrustc itself seems to finish compiling completely but rustc libraries/rustc itself doesn't seem to link.

The issue seems to be caused by the linker being unable to find several functions referenced by the Rust standard library. Some of these functions seem to be part of the system's C library (e.g. _NSGetArgc) while others seem to be Rust standard library functions (e.g. __rust_allocate - note that GCC suggests ___rust_allocate as a symbol, so maybe the demangling didn't work properly or something). Supposedly my GCC uses the system libc rather than install its own, which means that the "NS" functions should be available. As such, to me the issue then seems to be system headers not being #included properly in the mrustc-generated files or an issue with mangling/demangling.

Full console output

Part pertaining to error only

I am unable to see if this problem occurs with clang because it does not get to this stage before failing.

EDIT:
Looking at the Rust std lib source, all of the issues seem to be Rust standard library extern functions that interface with the system C library.

Also, mrustc --version does work:

MRustC v0.8.0 master:ebd8edeb
- Build time: Thu, 18 Jul 2019 13:01:26 +0000
- Commit: ebd8edeb4f1861943cc82d310564b1f592e63272 (dirty tree)

As does minicargo --help:

Usage: minicargo <package dir>

   Build a cargo package using mrustc. Point it at a directory containing Cargo.toml

--help, -h  : Show this help text
--script-overrides <dir> : Directory containing <package>.txt files containing the build script output
--vendor-dir <dir>       : Directory containing vendored packages (from `cargo vendor`)
--output-dir,-o <dir>    : Specify the compiler output directory
-L <dir>                 : Search for pre-built crates (e.g. libstd) in the specified directory
-j <count>               : Run at most <count> build tasks at once (default is to run only one)
-n                       : Don't build any packages, just list the packages that would be built

But trying to compile anything complains about crate std not being found or gives a parse error:

Theos-MacBook-Pro:mrustc-build-test theother$ ./bin/mrustc $HOME/rust_projects/hello_world/src/main.rs -o hello_world_test
Target Load: V V V
(0.00 s) Target Load: DONE
Parse: V V V
(0.00 s) Parse: DONE
LoadCrates: V V V
:0: error:0:Unable to locate crate 'std' in search directories
Abort trap: 6
Theos-MacBook-Pro:mrustc-build-test theother$ ./bin/mrustc $HOME/rust_projects/testlib/src/lib.rs -o testlib_test
Target Load: V V V
(0.00 s) Target Load: DONE
Parse: V V V
/Users/theother/rust_projects/testlib/src/lib.rs:3: Unexpected(TOK_RWORD_CRATE)
terminate called after throwing an instance of 'ParseError::Unexpected'
  what():  std::exception
Abort trap: 6

So this does appear to be the same issue as previously reported.

EDIT 2: I tested the way that the C output of libstd called _NSGetArgc() (through inline asm) in a separate C project, and it gives the same linking error of "symbol not found". However, if the function declaration is declared as a regular extern function (not inline asm), then the code calls the C std lib function. As such, you may be able to fix the macOS linking error by changing the generated code to declare regular extern functions rather than inline asm extern functions.

@thepowersgang
Copy link
Owner

Can you confirm that this is still an issue?

@thepowersgang thepowersgang added the stale No response received after potential fixes. label Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale No response received after potential fixes.
Projects
None yet
Development

No branches or pull requests

2 participants