Compile the dynamic library with `#![no_std]` attribute (`--crate-type dylib`) in macOS

[mssun]

There is an error in link time when compiling a dynamic library which is no_std in macOS.

Here is the lib.rs:

$ cat lib.rs
#![feature(lang_items)]
#![no_std]

#[lang = "eh_personality"] extern fn eh_personality() {}
#[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} }

pub fn foo() { }

Compile it:

$ rustc lib.rs --crate-type dylib
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-L" "/Users/sunmingshen/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "lib.0.o" "-o" "liblib.dylib" "lib.crate.metadata.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/sunmingshen/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "-Wl,-force_load,/var/folders/3r/y_ykzxz11y36c0rc71ds50g4g3sbtb/T/rustc.PUpdamjbR4od/libcore-9ba600218bb6e949.rlib" "-dynamiclib" "-Wl,-dylib"
  = note: Undefined symbols for architecture x86_64:
            "___umodti3", referenced from:
                core::fmt::num::_$LT$impl$u20$core..fmt..Display$u20$for$u20$i128$GT$::fmt::h8463a1a676e8ee2a in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::fmt::num::_$LT$impl$u20$core..fmt..Display$u20$for$u20$u128$GT$::fmt::h6ca2719d837aed88 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
            "_memcmp", referenced from:
                core::str::pattern::StrSearcher::new::h6d2d0dbec00d4a0b in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                _$LT$core..num..bignum..Big32x40$u20$as$u20$core..cmp..PartialEq$GT$::eq::hbe7f5ae8aabcbbd4 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                _$LT$core..num..bignum..tests..Big8x3$u20$as$u20$core..cmp..PartialEq$GT$::eq::h03e930fb3b50fa2c in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
            "_memset", referenced from:
                core::num::flt2dec::strategy::dragon::format_shortest::he26a0051f5c08ce1 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::flt2dec::strategy::dragon::format_exact::h9709ec9cce61c188 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::flt2dec::Part::write::h5c958cc3e4abc401 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::dec2flt::num::digits_to_big::hed468cab1e1db275 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::bignum::Big32x40::from_small::h0834d495142c5b04 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::bignum::Big32x40::div_rem::h8f4710ea0b7696f8 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
            "___muloti4", referenced from:
                core::num::from_str_radix::h41585106c29f58f9 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
            "___udivti3", referenced from:
                core::num::from_str_radix::h90268c29276886d4 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::_$LT$impl$u20$core..str..FromStr$u20$for$u20$u128$GT$::from_str::h56325653e340f0a5 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::fmt::num::_$LT$impl$u20$core..fmt..Display$u20$for$u20$i128$GT$::fmt::h8463a1a676e8ee2a in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::fmt::num::_$LT$impl$u20$core..fmt..Display$u20$for$u20$u128$GT$::fmt::h6ca2719d837aed88 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
            "_memcpy", referenced from:
                core::num::flt2dec::strategy::dragon::format_shortest::he26a0051f5c08ce1 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::flt2dec::strategy::dragon::format_exact::h9709ec9cce61c188 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::flt2dec::Part::write::h5c958cc3e4abc401 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::flt2dec::Formatted::write::h5671b2cd48514051 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::dec2flt::num::digits_to_big::hed468cab1e1db275 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::bignum::Big32x40::from_u64::h9bca3b5d00f012af in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                core::num::bignum::Big32x40::mul_digits::hf9c1d2eae1a420a9 in libcore-9ba600218bb6e949.rlib(core-9ba600218bb6e949.0.o)
                ...
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

Some version info:

$  rustc -V
rustc 1.22.0-nightly (6c476ce46 2017-09-25)

$ cc -v
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I read some code of linker.rs, but still did not find the reason. If someone can point out the main reason, I am glad to help.

[mattico]

It looks like compiler-builtins isn't being linked in for dylibs. I don't know if that is expected behavior, but you can try to work around this by adding a dependency to compiler-builtins.

[sfackler]

If you're trying to make a dynamic library for use with things other than Rust, the cdylib crate type is probably what you're looking for.

[mssun]

@sfackler, thanks for the suggestion.

Actually, I'm doing some simple experiments and found that my code could be compiled on the x86_64-unknown-linux-gnu target but failed on the x86_64-apple-darwin target.

I don't know if that is expected behavior or a bug in rustc.

[gnzlbg]

I'm hitting this same error with a cdylib when compiling in debug mode - is that intended ?

Undefined symbols for architecture x86_64:
            "_memcpy", referenced from:

If I compile with --release, the error disappears.

[steveklabnik]

Triage: i do not have access to a macos machine. Are folks still seeing this?

[mssun]

@steveklabnik Same error for rustc 1.46.0-nightly (346aec9b0 2020-07-11).

$ cat lib.rs
#![feature(lang_items)]
#![no_std]

use core::panic::PanicInfo;

#[lang = "eh_personality"] extern fn eh_personality() {}
#[panic_handler] fn panic_fmt(_info: &PanicInfo) -> ! { loop {} }

pub fn foo() { }

$ rustc lib.rs --crate-type dylib
Undefined symbols for architecture x86_64:
            "_memcmp", referenced from:
...

I'm using macOS 10.15.5.

[madsmtm]

I will argue that this is the "expected" behaviour, and that this issue should be closed:

You are asking rustc to build without a standard library, and as such it makes perfect sense that it also isn't linking standard system libraries (passes -nodefaultlibs to Clang). Never mind that that will basically never work for dynamic libraries on macOS/Darwin, as those are required by dyld to link to libSystem.dylib.

If you add either the following, or use -Clink-arg=-lSystem, the error disappears.

#[link(name = "System", kind = "dylib")]
extern "C" {}

I briefly considered if rustc could try to detect these cases, but I don't think that's really feasible, since there are many libraries that will result in linking libSystem.dylib implicitly, for example libc.dylib.

There is even a test for this here.

@rustbot label A-linkage

[jieyouxu]

https://github.com/rust-lang/rust/blob/df1b5d3cc2117f1ee96abca25678bc5f5604d450/tests/ui/extern-flag/auxiliary/panic_handler.rs#L4-L11

Closing as this is as intentional.