C runtime library is not linked on macOS

[lwshang]

Problem
rustc is not default to link C runtime library on macOS. I'm trying to write rust binding for a C library. That C library is shipped with my crate by a git submodule. The C library uses functionality provide by C runtime library. When I run cargo test without any special cargo configuration, it failed at linking stage because it cannot find the symbol __emutls_get_address which is provided in C runtime library.

The bug doesn't happen on Linux. On Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-46-generic x86_64). With the help of nightly rustc -Z print-link-args, I found out that rustc on linux has a link arg -lgcc_s which resolve to /usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.

Steps

1. Get my repo

$ git clone git@github.com:lwshang/q-capi.git --single-branch --branch rustc-link
$ cd q-capi
$ git submodule update --init

2. disable my workaround in .cargo/config

$ mv .cargo .cargo.bk

3. Try to build the test executable

$ cargo test
...
  = note: Undefined symbols for architecture x86_64:
            "___emutls_get_address", referenced from:
                l004 in e.o
...

Possible Solution(s)

Currently, I have a workaround to separately add link-args in .cargo/config which specify the path to a C runtime library. But this is just a temporary solution, since the path is version sensitive, it will be different on different version of macOS with different version of Xcode.

If we compile a C program, the final link process always links a C runtime library. Depends on the compiler, different lib will be linked.

1. If using macOS 10.14.3 system clang, it links /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a. (This is what I have in .cargo/config)

2. If using brew gcc-8, there is a link arg
   -lgcc_ext.10.5 which resolve to /usr/local/Cellar/gcc/8.3.0/lib/gcc/8/libgcc_ext.10.5.dylib.

If rustc default to link the first one (libclang_rt.osx.a), the special setting in .cargo/config will be non-necessary.

meta

rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-apple-darwin
release: 1.33.0
LLVM version: 8.0

[catap]

@lwshang were you using macports on this machine?

[madsmtm]

__emutls_get_address is implemented in compiler-rt, and is not included in compiler-builtins because it's not used by Rust. As far as I know, rustc guarantees nothing about the presence of such symbols.

I think this could be fixed in rustc by not passing -nodefaultlibs to the C linker, though for it to work with -Clinker-flavor=ld, we'd need to do something else (see #11937).

See also #109717, #81808 etc.

[bjorn3]

It should be possible to link with compiler-rt in addition to compiler-builtins. On x86_64-unknown-linux-gnu by default libgcc (the gcc counterpart to compiler-rt) is pulled in by default. compiler-builtins is structured such that it doesn't cause symbol conflicts even if compiler-rt or libgcc defines the same symbols.