Cannot build compiler_builtins_shim for i686 targets

[robert-w-gries]

While building i686 targets, there is an internal error while building compiler_builtins due to a missing file: fatal error: sys/cdefs.h: No such file or directory.

Initially I thought it was an issue with the compiler_builtins crate, but it seems like there's some magic that xargo needs to do in order to compile the C shims in compiler_builtins. Can I get some clarification on what xargo is expected to do? Did rust-lang/rust#49503 cause a regression in xargo?

From rust-lang/compiler-builtins#239 (comment)

Ah sorry indeed! Regardless to compile compiler-builtins you'll need a C compiler as some C shims are compiled. To disable this I believe xargo has necessary support to disable the C shims from being compiled, right?

Nightly Version

$ rustup show
[snip]

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.27.0-nightly (4b9b70c39 2018-04-09)

Reproduction Steps

$ rustup component add rust-src
$ cargo install xargo
$ xargo new foo --bin
     Created binary (application) `foo` project
$ cd foo/
$ echo "[dependencies.alloc]" > Xargo.toml
$ xargo build --target i686-unknown-linux-gnu

Error Message

$ xargo build --target i686-unknown-linux-gnu
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling cc v1.0.9                                                          
   Compiling core v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore)
   Compiling compiler_builtins v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/rustc/compiler_builtins_shim)
error: failed to run custom build command for `compiler_builtins v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/rustc/compiler_builtins_shim)`
process didn't exit successfully: `/tmp/xargo.Uqnk6A23t05W/target/release/build/compiler_builtins-f55661e1d900651e/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-changed=../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.c
[snip]
TARGET = Some("i686-unknown-linux-gnu")
OPT_LEVEL = Some("3")
TARGET = Some("i686-unknown-linux-gnu")
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("i686-unknown-linux-gnu")
TARGET = Some("i686-unknown-linux-gnu")
HOST = Some("x86_64-unknown-linux-gnu")
CC_i686-unknown-linux-gnu = None
CC_i686_unknown_linux_gnu = None
TARGET_CC = None
CC = None
HOST = Some("x86_64-unknown-linux-gnu")
CROSS_COMPILE = None
TARGET = Some("i686-unknown-linux-gnu")
HOST = Some("x86_64-unknown-linux-gnu")
CFLAGS_i686-unknown-linux-gnu = None
CFLAGS_i686_unknown_linux_gnu = None
TARGET_CFLAGS = None
CFLAGS = None
DEBUG = Some("false")
TARGET = Some("i686-unknown-linux-gnu")
CC_i686-unknown-linux-gnu = None
CC_i686_unknown_linux_gnu = None
HOST_CC = None
CC = None
CFLAGS_i686-unknown-linux-gnu = None
CFLAGS_i686_unknown_linux_gnu = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m32" "-march=i686" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-DVISIBILITY_HIDDEN" "-o" "/tmp/xargo.Uqnk6A23t05W/target/i686-unknown-linux-gnu/release/build/compiler_builtins-2536234101d25e1c/out/../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.o" "-c" "../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.c"
cargo:warning=In file included from /usr/include/limits.h:25:0,
cargo:warning=                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/limits.h:168,
cargo:warning=                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/syslimits.h:7,
cargo:warning=                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/limits.h:34,
cargo:warning=                 from ../../libcompiler_builtins/compiler-rt/lib/builtins/int_lib.h:68,
cargo:warning=                 from ../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.c:15:
cargo:warning=/usr/include/features.h:367:25: fatal error: sys/cdefs.h: No such file or directory
cargo:warning=compilation terminated.
exit code: 1

--- stderr
thread 'main' panicked at '

Internal error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m32" "-march=i686" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-DVISIBILITY_HIDDEN" "-o" "/tmp/xargo.Uqnk6A23t05W/target/i686-unknown-linux-gnu/release/build/compiler_builtins-2536234101d25e1c/out/../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.o" "-c" "../../libcompiler_builtins/compiler-rt/lib/builtins/absvdi2.c" with args "cc" did not execute successfully (status code exit code: 1).

[FenrirWolf]

I ran into a similar issue for a project of mine that cross-compiles to ARM. The problem seems to be that the cc crate is either failing to select a C compiler when invoked by xargo, or it's selecting your host's compiler rather than the target's cross-compiler.

Fortunately cc can be configured with various environment variables, so try compiling your project with CC=<cross-compiler here> xargo build --target i686-unknown-linux-gnu and see if that gets you any farther.

[FenrirWolf]

Also, the reason why a C cross-compiler is suddenly required is because the Rust sysroot builds compiler-builtins with the c feature enabled (see https://github.com/rust-lang/rust/blob/master/src/rustc/compiler_builtins_shim/Cargo.toml#L37 and https://github.com/rust-lang-nursery/compiler-builtins/#when-and-how-to-use-this-crate).

Previously, us users of compiler-builtins would pull it in manually via Xargo.toml, where we could control which features we wanted enabled for the crate. But now that the version of compiler-builtins from the sysroot is being automagically injected, we're locked into using whatever features the sysroot enables whether we care about cross-compiling the C shims or not.

EDIT: Rather, it might be alloc and a number of other crates in the sysroot now having an explicit dependency on the compiler-builtins-shim crate that causes the feature to always be enabled. Might not apply to a core-only project but I haven't tested that.

[peterbudai]

The same happened to my project. With the latest 1.27.0 nightly and Xargo 0.3.12 it now fails to build.
I am cross compiling an EFI executable (Win64) from Linux with a custom target JSON.

Until the update, it went seamlessly, I used only the required compiler_builtins components as an external crate. Now it requires cc-rs which at first was not able to find the correct cross compiler (clang-cl) in this case.

I fixed it by specifying CC_my_target_triple=clang-cl in the command line, and some parts of compiler_builtins can compile, however it gets to a point where a C source file includes <stdlib.h>.

I managed to fix it by also adding CFLAGS_my_target_triple="/I/usr/include", now it goes through the compilation phase, but now it could not find lib.exe for library linking.

I tried to specify AR_my_target_triple=llvm-lib as suggested by cc-rs's manual, however cc-rs seems like just ignoring it.

running: "clang-cl" "/nologo" "/MD" "/O2" "/I/usr/include" "-m64" "/Zl" "/D__func__=__FUNCTION__" "/Fo/tmp/xargo.tI4w26ZhBfOI/target/my_target_triple/release/build/compiler_builtins-e434171d7b724fe5/out/../../libcompiler_builtins/compiler-rt/lib/builtins/ucmpdi2.o" "/c" "../../libcompiler_builtins/compiler-rt/lib/builtins/ucmpdi2.c"
exit code: 0
TARGET = Some("my_target_triple")
OPT_LEVEL = Some("3")
TARGET = Some("my_target_triple")
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("my_target_triple")
HOST = Some("x86_64-unknown-linux-gnu")
CC_my_target_triple = Some("clang-cl")
TARGET = Some("my_target_triple")
HOST = Some("x86_64-unknown-linux-gnu")
CFLAGS_my_target_triple= Some("/I/usr/include")
DEBUG = Some("false")
running: "clang-cl" "/nologo" "/MD" "/O2" "/I/usr/include" "-m64" "/Zl" "/D__func__=__FUNCTION__" "/Fo/tmp/xargo.tI4w26ZhBfOI/target/my_target_triple/release/build/compiler_builtins-e434171d7b724fe5/out/../../libcompiler_builtins/compiler-rt/lib/builtins/ucmpti2.o" "/c" "../../libcompiler_builtins/compiler-rt/lib/builtins/ucmpti2.c"
exit code: 0
TARGET = Some("my_target_triple")
running: "lib.exe" "/OUT:/tmp/xargo.tI4w26ZhBfOI/target/my_target_triple/release/build/compiler_builtins-e434171d7b724fe5/out/libcompiler-rt.a" "/nologo" "@/tmp/xargo.tI4w26ZhBfOI/target/my_target_triple/release/build/compiler_builtins-e434171d7b724fe5/out/libcompiler-rt.a.args"

--- stderr
thread 'main' panicked at '

Internal error occurred: Failed to find tool. Is `lib.exe` installed?
', /home/.../.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cc-1.0.15/src/lib.rs:2158:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Even if I managed to fix cc-rs this situation does not seem ideal.

Could you please show me how to turn off the "c" feature for the integrated compiler_builtins library? I tried to disable default features from Xargo.toml but no success so far.

[FenrirWolf]

If your code depends on alloc (or anything else from the std facade other than core) then as far as I can tell you're locked into the compiler-builtins features that it selects. Looking at the build script error, it does seem like the script is trying to use lib.exe but it can't find the executable. Maybe try temporarily adding it to your PATH?

[peterbudai]

Unfortunately adding it to PATH won't help as it is a Linux machine and cannot run an .exe :)
What I was trying to achieve to make cc-rs use llvm-lib instead of lib.exe, as I did it for clang-cl and lld-link. It seems line cc-rs sticks to lib.exe instead of relying on AR environment variable when the target triple contains the string msvc, but it seems like a missing feature there not in Xargo.

[phil-opp]

I created a simplified fork of xargo at rust-osdev/cargo-xbuild, which just always compiles core, compiler_builtins and alloc without configuration ability. The advantage of hard-coding those is that we can hack the alloc compilation so that it uses compiler_builtins with the "mem" feature and without the "c" feature. Maybe this fixes your problems.

[peterbudai]

@phil-opp Yes, cargo xbuild did the job, thank you.
Now I just have to rewrite my global allocator, since GlobalAlloc trait support was merged since then :)

[gurry]

I have a similar problem. I'm seeing a breakage when I updated to nightly-2018-09-16-x86_64-pc-windows-msvc. Earlier I was using nightly-2018-03-30-x86_64-pc-windows-msvc and everything worked fine.

I'm also building a UEFI application and I'm using xargo and a custom target shown below:

Expand to see

```json { "arch": "x86_64", "cpu": "x86-64", "crt-static-allows-dylibs": true, "crt-static-respected": true, "data-layout": "e-m:w-i64:64-f80:128-n8:16:32:64-S128", "dll-prefix": "", "dll-suffix": ".efi", "dynamic-linking": true, "env": "msvc", "exe-suffix": ".efi", "executables": true, "has-elf-tls": true, "is-builtin": false, "is-like-msvc": true, "is-like-windows": true, "linker": "link.exe", "linker-flavor": "msvc", "llvm-target": "x86_64-pc-windows-msvc", "max-atomic-width": 64, "os": "windows", "pre-link-args": { "msvc": [ "/NOLOGO", "/SUBSYSTEM:EFI_APPLICATION" ] }, "staticlib-prefix": "", "staticlib-suffix": ".lib", "target-c-int-width": "32", "target-endian": "little", "target-family": "windows", "target-pointer-width": "64", "vendor": "unknown", "panic-strategy": "abort", "singlethread": true } ```

My host machine is Windows 10 and I'm using VS 2017's build tools (this is one primary difference between mine and @peterbudai's case environment-wise). Earlier the build worked fine, but when I switched to nightly-2018-09-16-x86_64-pc-windows-msvc I started seeing the below error:

D:\Projects\Rust\peerboot>xargo  build --target x86_64-unknown-efi
    Updating crates.io index
   Compiling cc v1.0.25
   Compiling core v0.0.0 (C:\Users\gurinder.singh\.rustup\toolchains\nightly-2018-09-16-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore)
   Compiling compiler_builtins v0.0.0 (C:\Users\gurinder.singh\.rustup\toolchains\nightly-2018-09-16-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\rustc\compiler_builtins_shim)
error: failed to run custom build command for `compiler_builtins v0.0.0 (C:\Users\gurinder.singh\.rustup\toolchains\nightly-2018-09-16-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\rustc\compiler_builtins_shim)`
process didn't exit successfully: `C:\Users\GURIND~1.SIN\AppData\Local\Temp\xargo.CLhBM4IFqVT6\target\release\build\compiler_builtins-551350075561f652\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\absvdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\absvsi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\absvti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\addvdi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\addvsi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\addvti3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\apple_versioning.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\clzdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\clzsi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\clzti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\cmpdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\cmpti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ctzdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ctzsi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ctzti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\divdc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\divsc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\divxc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\extendhfsf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ffsdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ffsti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\x86_64/floatdisf.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\x86_64/floatdixf.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\int_util.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\muldc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\mulsc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\mulvdi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\mulvsi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\mulvti3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\mulxc3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negdf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negsf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negvdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negvsi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\negvti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\paritydi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\paritysi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\parityti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\popcountdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\popcountsi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\popcountti2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\powixf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\subvdi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\subvsi3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\subvti3.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\truncdfhf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\truncdfsf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\truncsfhf2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ucmpdi2.c
cargo:rerun-if-changed=../../libcompiler_builtins\compiler-rt/lib/builtins\ucmpti2.c
TARGET = Some("x86_64-unknown-efi")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-pc-windows-msvc")
CC_x86_64-unknown-efi = None
CC_x86_64_unknown_efi = None
TARGET_CC = None
CC = None
CROSS_COMPILE = None
CFLAGS_x86_64-unknown-efi = None
CFLAGS_x86_64_unknown_efi = None
TARGET_CFLAGS = None
CFLAGS = None
DEBUG = Some("false")
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "/Zl" "-D__func__=__FUNCTION__" "-o" "C:\\Users\\GURIND~1.SIN\\AppData\\Local\\Temp\\xargo.CLhBM4IFqVT6\\target\\x86_64-unknown-efi\\release\\build\\compiler_builtins-e8f577f13bcd0c00\\out\\../../libcompiler_builtins\\compiler-rt/lib/builtins\\absvdi2.o" "-c" "../../libcompiler_builtins\\compiler-rt/lib/builtins\\absvdi2.c"

--- stderr
thread 'main' panicked at '

Internal error occurred: Failed to find tool. Is `cc` installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

', C:\Users\gurinder.singh\.cargo\registry\src\git.luolix.top-1ecc6299db9ec823\cc-1.0.25\src\lib.rs:2260:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I'm running this inside Visual Studio developer prompt and cl.exe is in path then why is cc-rs trying to use linux's cc? Is this due to something wrong in my target spec? Is the CC = None line in the error a clue? I didn't have to set any CC* variables with the previous nightly.

Not sure sure if it's a xargo or a cc-rs bug. Any help will be greatly appreciated :slight_smile:.