PSA: [breaking-change] `extern crate compiler_builtins` is now included in #![no_std] crates


As of the latest nightly (nightly-2018-04-08) the expansion of #![no_std] contains extern crate compiler_builtins. This unstable crate contains compiler intrinsics, like addsf3, which LLVM uses (calls) to perform operations, like addition of single precision floats, when they can’t be performed using native instructions. Some targets need this crate to link properly.

This is a breaking change:

If you had a crate that directly depended on the compiler_builtins crate you’ll have to remove the extern crate bit:



-extern crate compiler_builtins;

  // ..

But this also means you can drop the compiler_builtins_lib feature gate, which is a good thing.

Also, if you were using Xargo (which requires nightly) v0.3.11 or older (NOTE that you don’t need Xargo if you are cross compiling for ARM Cortex-M) and you were building a sysroot that only contained core you’ll have to add / modify Xargo.toml to also (cross) compile the compiler_builtins crate.

$ cat Xargo.toml
stage = 0

features = ["mem"]
stage = 1

Alternatively, you can use the upcoming Xargo v0.3.12 which will compile both core and compiler_builtins by default.

This change is part of the effort towards making embedded development possible on the stable channel.

See this issue for previous discussion regarding this change.


@japaric I guess this requires a new cortex-m-rt release to cope with the change?


So post crossed action. :smiley: Thanks for the swift update, @japaric.


So I’ve tried to move from rlibc to compiler_builtins with the mem feature. I’ve added

stage = 0

features = ["mem"]
stage = 1

to Xargo.toml, and removed the rlibc dependency. However, I get this:

error[E0464]: multiple matching crates for `compiler_builtins`
  = note: candidates:
          crate `compiler_builtins`: /home/isaac/.xargo/lib/rustlib/x86_64-pebble-ker
          crate `compiler_builtins`: /home/isaac/.xargo/lib/rustlib/x86_64-pebble-ker

error[E0463]: can't find crate for `compiler_builtins`

Any ideas?


Looks like a bad cache. Try cargo clean and removing the Xargo sysroot: rm -rf ~/.xargo.


Had tried that, but tried it again, with no success. Same error.


features = ["mem"]
stage = 1

compiles successfully, but obviously then can’t link since it doesn’t have memcpy and such.


Could you open an issue in the Xargo repo providing instructions on how to reproduce the problem?


I’m not sure I have a reliable reproduction. I updated Xargo to 0.3.12 and removed the entry from Xargo.toml, and compiler_builtins is now included automatically (and doesn’t cause the multiple crates problem), but does not have the memcpy etc. symbols needed for linking, even with the mem feature added again. I’ve resorted to leaving it and re-adding the dependency on rlibc. I’ll try again at some point, and if it still doesn’t work I’ll dig deeper and file it on the repo.