Cross-compiling [no_std] code - libcore and compiler_builtins not found - rust

I'm trying to follow the steps explained in Embeddonomicon to compile the smallest #![no-std] program, but for a new target on a new architecture.
The architecture is upstreamed in LLVM as an experimental target ("ARC") but its not used by rustc, so first I enabled it in the LLVM that comes with Rust as explained here: run ./x.py setup then update the config.toml:
[llvm]
download-ci-llvm = false
ninja = true
targets = "X86"
experimental-targets = "ARC"
Then I manually added the support for the arch following the steps explained here (using this commit as an example):
created rustc_target/src/abi/call/arc.rs
updated rustc_llvm/src/lib.rs
etc
Then I added the target file arc-pc-unknown-gnu.json and made it visible through RUST_TARGET_PATH envvar:
{
"arch": "arc",
"cpu": "generic",
"abi": "eabi",
"c-enum-min-bits": 8,
"data-layout": "e-m:e-p:32:32-i64:32-f64:32-v64:32-v128:32-a:0:32-n32",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"executables": true,
"features": "",
"linker": "rust-lld",
"linker-flavor": "ld.lld",
"llvm-target": "arc-pc-unknown-gnu",
"max-atomic-width": 32,
"atomic-cas": false,
"panic-strategy": "abort",
"relocation-model": "static",
"target-pointer-width": "32"
}
Built the compiler: ./x.py build -i --target=arc-pc-unknown-gnu library/core. It finished successfully, I could see stage1 libs for the arc-pc-unknown-gnu target
I thought this would be enough, but the code was not compiling because of the following issues:
$ rustc --emit=llvm-ir -o rust_main.ll -C panic=abort --target arc-pc-unknown-gnu src/main.rs
error[E0463]: can't find crate for `core`
|
= note: the `arc-pc-unknown-gnu` target may not be installed
= help: consider downloading the target with `rustup target add arc-pc-unknown-gnu`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
error[E0463]: can't find crate for `compiler_builtins`
error[E0412]: cannot find type `PanicInfo` in this scope
--> src/main.rs:18:18
This is weird because on the previous step I should have compiled these very libs for my target...
Then I though that perhaps I needed to rebuild libcore again using cargo build-std (although I don't know why exactly, but someone on the web mentioned this)? I tried this, but now there are the following errors:
$ cargo build -Z build-std=core --target arc-pc-unknown-gnu
Compiling compiler_builtins v0.1.70
Compiling core v0.0.0 (/home/valeriyk/proj/rust-arc/1.60.0/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/core)
error[E0463]: can't find crate for `std`
error: cannot find macro `println` in this scope
--> /home/valeriyk/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.70/build.rs:88:9
|
88 | println!("cargo:rustc-cfg=kernel_user_helpers")
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /home/valeriyk/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.70/build.rs:78:9
|
78 | println!("cargo:rustc-cfg=thumb_1")
| ^^^^^^^
...
How come that libcore needs std? I just want to have it cross-compiled using the stage1 rustc, and then picked up during my #![no_std] example compilation. Any guidance is appreciated.

That's how I solved the issue:
Use the right rustc source code. I started with a stable version whose libcore was not compatible with the latest compiler_builtins. See here for more details. Then I needed to upgrade to the latest nightly.
When building the compiler, don't ask to build libcore for the final stage, instead build rustc only:
$ ./x.py build -i --stage=1 --target=arcv2-none-elf32 compiler/rustc
Use the following for the .cargo/config.toml, don't use Xargo or -Z build-std=core. The compiler-builtins-mem thing is explained here.
[unstable]
build-std = [
"core",
"compiler_builtins"
]
build-std-features = ["compiler-builtins-mem"]
[build]
target = "arcv2-none-elf32"
Build the code with a simple cargo build. It compiled just fine, although it failed at linking later - but that's another story.

Related

Could not compile `lazy_static`

I'm having a hard time cross-compiling an embedded Rust project that worked before for a raspberry pi. I have all the needed deps in Cargo.toml but on doing:
$ cargo build --target thumbv7m-none-eabi
I get the following error.
error[E0463]: can't find crate for `std`
--> /home/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-1.4.0/src/inline_lazy.rs:9:1
|
9 | extern crate std;
| ^^^^^^^^^^^^^^^^^ can't find crate
|
= note: the `thumbv7m-none-eabi` target may not support the standard library
= help: consider building the standard library from source with `cargo build -Zbuild-std`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static` due to previous error
$ rustup show
installed targets for active toolchain
--------------------------------------
thumbv7m-none-eabi
x86_64-unknown-linux-gnu
active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.64.0-nightly (38b72154d 2022-07-11)
Compilation used to work previously without lazy_static as a dependency in cargo.toml,now I don't understand why this is happening.
By default lazy_static depends on the rust standard library, which as the compiler told you
may not be supported on the thumbv7m-none-eabi target
If you do not need the standard library in your project you can enable the no-std feature of lazy_static like this:
lazy_static = { version = "1.5.0", features = ["spin_no_std"] }
as described here.

Build fails with Error: Pear requires a 'dev' or 'nightly' version of rustc even after a successful rustup override set nightly

Windows 10
rustup 1.23.1 (3df2264a9 2020-11-30)
default rustc 1.50.0 (cb75ad5db 2021-02-10)
project rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
rocket = "0.4.4"
I'm trying to build a rust project with rocket but I always get this error when compiling, even after successfully overwriting the project's toolchain:
D:\GitHub\Learning-Rust\poke_api> rustup override set nightly
info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: override toolchain for 'D:\GitHub\Learning-Rust\poke_api' set to 'nightly-x86_64-pc-windows-msvc'
nightly-x86_64-pc-windows-msvc unchanged - rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
PS D:\GitHub\Learning-Rust\poke_api> cargo build
Compiling winapi v0.3.9
Compiling serde_derive v1.0.124
Compiling rocket v0.4.7
Compiling pear_codegen v0.1.4
Compiling rocket_codegen v0.4.7
Compiling proc-macro2 v1.0.24
Compiling pq-sys v0.4.6
Compiling aho-corasick v0.6.10
Compiling serde_json v1.0.64
error: failed to run custom build command for `pear_codegen v0.1.4`
Caused by:
process didn't exit successfully: `D:\GitHub\Learning-Rust\poke_api\target\debug\build\pear_codegen-e182711746033ac9\build-script-build` (exit code: 101)
--- stderr
Error: Pear requires a 'dev' or 'nightly' version of rustc.
Installed version: 1.48.0 (2020-11-16)
Minimum required: 1.31.0-nightly (2018-10-05)
thread 'main' panicked at 'Aborting compilation due to incompatible compiler.', C:\Users\gabre\.cargo\registry\src\github.com-1ecc6299db9ec823\pear_codegen-0.1.4\build.rs:24:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
I had a similar issue while using rocket. Same error message too, Error: Pear requires a 'dev' or 'nightly' version of rustc.
If you get to the get-started page on rocket framework website. It says, "Rocket makes abundant use of Rust's syntax extensions and other advanced, unstable features. Because of this, we'll need to use a nightly version of Rust."
My issue was I was not using a nightly version of rust. Running this on my terminal in my project directory did it for me.
rustup override set nightly
If you check the cargo version for that directory after,
cargo version
you will confirm it has switched to nightly version
Failed compilation even with nightly
It looks like you have some outdated dependencies (pear-codegen probably being the one that causes trouble), updating these may resolve the compilation issues.
General notes on how to override the toolchain
Using rustups override works fine, but it is bound to your local rustup configuration and not specified inside the project.
In order to achieve this, thereby making the project more portable and allowing others to always use the correct toolchain, I would recommend the toolchain file. It can look something like this (example taken from linked page) and will accurately specify the required toolchain only for the containing project.
# rust-toolchain.toml
[toolchain]
channel = "nightly-2020-07-10"
components = [ "rustfmt", "rustc-dev" ]
targets = [ "wasm32-unknown-unknown", "thumbv2-none-eabi" ]
profile = "minimal"
For your purposes a simple configuration like this will most likely be all you need, although adding the components you want to use would be beneficial.
[toolchain]
channel = "nightly"
My issue was with rust-analyser that wouldn't start because multiple rocket dependencies needed nightly or dev version of rustc.
These steps fixed my issue:
Switch to nightly for my rocket project by running rustup override set nightly inside the app folder.
Remove all target folders in my project. (I also had one in root)
Manually remove the faulty cached packages from cargo cache. cd ~/.cargo/registry/cache/github.com-xxxxxxxxxxxx && rm -r pear_codegen-0.1.5/

Why does clap fail to compile when added to Cargo.toml?

Summary
I'm fairly new to Rust and decided to use it to port an existing project into it. I intended to use clap to handle CLI options, but I keep getting errors.
What do I need to do for clap to install correctly so that it's usable in my project as a dependency (e.g. extern crate clap; [...] use clap::App; [...]?
I haven't had problems with other crates (so far), so I'm not sure what's so different here or if there's a problem with the crate itself.
I've already seen a few questions (e.g. this one), which simply suggests that the dependency be added into the .toml file or don't seem to provide a solution to what I'm seeing.
I'm in Ubuntu Linux, if that makes a difference.
What I Tried
Adding clap = "2.33.0" to my Cargo.toml file (see https://crates.io/crates/clap) causes VSCode (through RLS) to log the following:
{
"resource": "[...]/Projects/takeout/Cargo.toml",
"owner": "rust",
"severity": 8,
"message": "Could not compile `clap`.\nprocess didn't exit successfully: `[...]/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rls --crate-name clap [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.0/src/lib.rs --color never --crate-type lib --emit=dep-info,metadata -C debuginfo=2 --cfg 'feature=\"ansi_term\"' --cfg 'feature=\"atty\"' --cfg 'feature=\"color\"' --cfg 'feature=\"default\"' --cfg 'feature=\"strsim\"' --cfg 'feature=\"suggestions\"' --cfg 'feature=\"vec_map\"' -C metadata=630980a214d5fd10 -C extra-filename=-630980a214d5fd10 --out-dir [...]/Projects/takeout/target/rls/debug/deps -L dependency=[...]/Projects/takeout/target/rls/debug/deps --extern ansi_term=[...]/Projects/takeout/target/rls/debug/deps/libansi_term-1510a9addefc0253.rmeta --extern atty=[...]/Projects/takeout/target/rls/debug/deps/libatty-7c4847fd9fc1e3d9.rmeta --extern bitflags=[...]/Projects/takeout/target/rls/debug/deps/libbitflags-8369a9aec15a5abb.rmeta --extern strsim=[...]/Projects/takeout/target/rls/debug/deps/libstrsim-301d1cf239e9cd24.rmeta --extern textwrap=[...]/Projects/takeout/target/rls/debug/deps/libtextwrap-a799d71e2d028df4.rmeta --extern unicode_width=[...]/Projects/takeout/target/rls/debug/deps/libunicode_width-58e38dd9d658dcfb.rmeta --extern vec_map=[...]/Projects/takeout/target/rls/debug/deps/libvec_map-4f8e59c92e9953d8.rmeta --cap-lints allow --error-format=json --sysroot [...]/.rustup/toolchains/stable-x86_64-unknown-linux-gnu` (exit code: 101)",
"startLineNumber": 1,
"startColumn": 1,
"endLineNumber": 10000,
"endColumn": 1
}
According to the README in the clap repo itself, just adding it should work:
For full usage, add clap as a dependency in your Cargo.toml to use from crates.io:
[dependencies]
clap = "~2.33"
But it doesn't.
I've tried it with and without the ~ prefix as well as clap = {version = "2.33", features = ["yaml"]}, which is also shown in the repo, but no luck. (Yes, I'm trying to load the CLI options from a .yaml file.)
Trying cargo install clap --version 2.33.0 from the shell simply returns an error message saying: error: specified package has no binaries.
Aiming directly at the Git repo also produces the same error message:
cargo install --git https://github.com/clap-rs/clap.git --tag v2.31.2 --features yaml 101 ↵
Updating git repository `https://github.com/clap-rs/clap.git`
Installing clap v2.31.2 (https://github.com/clap-rs/clap.git?tag=v2.31.2#07c15d28)
error: specified package has no binaries
Note that there's no v2.33.0 tag in the Git repo (at the time of this writing).
Bonus if you know how to get VSCode to stop marking everything as an error:
cargo install
There's misunderstanding about the cargo install command. You can learn more about it here.
This command manages Cargo’s local set of installed binary crates. Only packages which have executable [[bin]] or [[example]] targets can be installed, and all executables are installed into the installation root’s bin folder.
It's not your case. The only thing you have to do is to list clap in the dependencies section (Cargo.toml). That's all. No need to use cargo install at all. cargo build, cargo run, ... commands will download & compile & statically link all dependencies.
An example
Folder structure:
.
├── Cargo.toml
└── src
   ├── cli.yaml
   └── main.rs
Current directory:
$ pwd
/Users/robertvojta/Projects/stackoverflow/clap-yaml
Cargo.toml content:
[package]
name = "clap-yaml"
version = "0.1.0"
authors = ["Zrzka"]
edition = "2018"
[dependencies]
clap = { version = "2.33.0", features = ["yaml"] }
src/cli.yaml content:
name: clap-yaml
version: "1.0"
author: Zrzka
about: Stackoverflow sample
args:
- lang:
short: l
long: lang
default_value: cz
takes_value: true
possible_values:
- cz
- en
src/main.rs content:
use clap::{App, load_yaml};
fn main() {
let yaml = load_yaml!("cli.yaml");
let matches = App::from_yaml(yaml).get_matches();
match matches.value_of("lang").unwrap() {
"cz" => println!("Ahoj"),
"en" => println!("Hello"),
_ => unreachable!("see possible_values in yaml, handled by clap"),
};
}
Run it with cargo:
$ cargo -q run -- --lang en
Hello
Run it directly:
$ cargo build
...
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
$ target/debug/clap-yaml --lang cz
Ahoj
Visual Studio Code
I still have vscode complaining and underlining everything in red in the Cargo.toml file. Any suggestions to fix this completely? It seems close to a full resolution.
I can confirm that this problem do exist in Rust 1.34.0. I did install this version and I've got same symptoms:
could not compile clap
the whole Cargo.toml is underlined (error)
There're two ways how to fix this.
Update your Cargo.toml file dependencies section manually if you'd like to stick with Rust 1.34.0:
[dependencies]
bitflags = "=1.0.4"
clap = { version = "2.33.0", features = ["yaml"] }
Or update your Rust toolchain to >= 1.35.0.
I just tested both ways and it works.
Related issues:
Could not compile clap. process didn't exit successfully
Compiler panics on latest RLS when compiling crates that depend on bitflags 1.0.5

How to troubleshoot why cargo/rustc links in rust standard library symbols even when no_std is used?

I am trying to create an embed-friendly executable (small footprint and without dependency on the Rust standard library) that uses a library (wasmi) that already has support for a no_std build. New to Rust, I am simply piecing together instructions, but the gist of it appears to be follow the steps.
For the executable:
#![no_std]
#![no_main]
use core::panic::PanicInfo;
/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
#[no_mangle]
pub extern "C" fn _start(_argc: isize, _argv: *const *const u8) -> ! {
interpret(_argc, _argv);
loop {}
}
That is to:
include #![no_std]
define our entry (not main since we don't have a runtime that will call it)
and define a panic handler since the Rust std lib is not included to define it for us.
My Cargo file to compile this looks like this:
[package]
name = "driver"
version = "0.1.0"
edition = "2018"
[dependencies.wasmi]
path = "../../github_dev/wasmi"
features = ["core"]
default-features = false
test=false
bench=false
[profile.release]
panic = "abort"
lto = true
incremental=false
debug=true
opt-level = "z"
test=false
bench=false
and produces a very small binary that excludes any standard library symbols (using nm to check) and runs as expected.
The problem occurs when I actually try to call a function from the wasmi library. It is built with no_std via the features=core line. Doing an nm on the files in release/deps/libwasmi-*.rlib shows no standard library symbols. However when linking occurs with this command:
rustc --release --verbose -- -C link-arg=-nostartfiles
it leads to:
Compiling driver v0.1.0 (/home/my_home/wasmi_embed/driver)
Running rustc --edition=2018 --crate-name driver src/main.rs --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C link-arg=-nostartfiles -C metadata=957eda2e590447ba -C extra-filename=-957eda2e590447ba --out-dir /home/my_home/wasmi_embed/driver/target/release/deps -L dependency=/home/my_home/wasmi_embed/driver/target/release/deps --extern libc=/home/my_home/wasmi_embed/driver/target/release/deps/liblibc-f7fb773c7b059a14.rlib --extern wasmi=/home/my_home/wasmi_embed/driver/target/release/deps/libwasmi-534aef1926b4eb6c.rlib
and an error occurs:
error[E0152]: duplicate lang item found: panic_impl.
--> src/main.rs:31:1
|
31 | / pub extern fn panic(_info: &PanicInfo) -> ! {
32 | | loop {}
33 | | }
| |_^
|
= note: first defined in crate `std`.
It seems Rust is trying to link in standard library support for at least panic handling, but I don't know why.
I would like help to understand why and to understand how to prevent it.
If I remove the panic_impl attribute then my executable compiles, but it includes a lot of standard library symbols that I am trying to prevent.
The example symbols I see are:
my_home#my_puter:~/wasmi_embed/driver/target/release$ nm --demangle -A -a -B -s --line-number test_2018 2>/dev/null | grep std
driver:00000000000264c0 t rust_begin_unwind /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:311
driver:00000000000264a0 t rust_oom /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/alloc.rs:203
driver:000000000001f490 t rust_panic /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:524
driver:0000000000025aa0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::get::he4f810e299a2e0b4 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:372
driver:00000000000259a0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::box_me_up::hd8430725259668a8 /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:367
driver:0000000000021520 t _$LT$std..sys_common..process..DefaultEnvKey$u20$as$u20$core..borrow..Borrow$LT$std..ffi..os_str..OsStr$GT$$GT$::borrow::hbacd0cd7d7fbf1c1/rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/sys_common/process.rs:27
driver:0000000000021570 t _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$$LP$dyn$u20$std..error..Err
... plus more
The above symbols are not found in any of the rlib files under the dep directory including libwasmi, nor are they found in the driver executable when not calling libwasmi code.
I've read a similar issue (hence my test=false and bench=false in the Cargo.toml) but that did not help. I've tried to build with just rustc with varying commands (excluding Cargo) but the error is the same. I've tried to compile wasmi as a static library (ar) and link it in, but being new to Rust I was spending a lot of time trying to link it in and it just wasn't happening.
I resolved this after seeking some help in the rust forums. enter link description here. Specifically, was not able to determine what was responsible for rust std lib being linked into my executable ... was it an issue with a crate or an issue with cargo or an issue with rustc or an issue with the linker. I did not know where the problem was born, but based on similar bugs filed I figured that somehow a crate was being compiled to bring in std lib unexpected. Turns out bug enter link description here was not related even though the error message was the same. I did not have an issue with unexpected propagations form different type of dependencies (dev-dependencies and build-dependencies). I tried all these techniques to pinpoint what was bringing in std lib:
I tried using cargo tree to list dependencies to list all the crate
dependencies:
wasmi v0.4.3 (/home/jlb6740/github_dev/wasmi)
├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder)
├── hashbrown v0.1.8 (/home/jlb6740/github_dev/hashbrown)
│ ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
│ └── scopeguard v0.3.3 (/home/jlb6740/github_dev/scopeguard)
├── libm v0.1.2
├── memory_units v0.3.0
└── parity-wasm v0.31.0 (/home/jlb6740/github_dev/parity-wasm)
└── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
I tried using cargo rustc --verbose … but at this time verbose does
not indicate anything was using default features which may include
using std
I tried using cargo metadata … this generated a long list of
dependencies that was hard to parse, but I did see some instances
where scopeguard and byteorder had default features requiring std
support. I downloaded all of these crates and just hardcoded
attributes so that the crates would only build with no_std support.
I tried looking at the deps/ output and did an nm on all of the
rlibs to see if any of the libraries used symbols found in std. I
could not find that that was the case. I thought rlibs were like
static libraries and that anything they used would be included in
the rlib but apparently not.
I looked at cargo rustc -- -C --print-link-args to check out linker
flags but I could not find anything obvious telling me it was
bringing in std lib.
None of these things helped me to pinpoint what was introducing std lib. Ultimately the suggestion at the rust forums was to use cargo check for a target that does not allow std lib at all. Those with a * listed here: enter link description here have only core support. I tried that, running with --target=thumbv7m-none-eabi and saw:
error[E0463]: can’t find crate for alloc
–> /home/jlb6740/github_dev/hashbrown/src/lib.rs:44:1
|
44 | extern crate std as alloc;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ can’t find crate
Turns out it was hashbrown which was a dependency of a dependency of my executable. It built no_std by default but had an extern std linked under a different name and which was guarded by a feature called “nightly”. The guard was disabled in my efforts to not build anything but no_std. Nothing I’d tried alerted me to the crate which was responsible until this. Seems there should be a better way to get a more comprehensive list of crate dependencies than what cargo tree provided, but changing the wasmi cargo to make sure the nightly feature was set solved my issue.

Statically linking ffmpeg-sys on Amazon Linux fails with undefined references

My project depends on the ffmpeg-sys crate which is configured to build statically, as follows:
[dependencies.ffmpeg-sys]
version = "3.4.1"
default-features = false
features = ["avcodec", "avformat", "swresample", "build", "static"]
My project consists of a single simple file:
extern crate ffmpeg_sys;
use ffmpeg_sys::av_register_all;
fn main() {
unsafe { av_register_all() };
println!("Hello, world!");
}
When compiling with cargo build I get the following error:
Compiling sample v0.1.0 (file:///home/ec2-user/sample)
error: linking with 'cc' failed: exit code: 1 | = note: "cc"
"-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L"
[... elided for clarity ...]
In function 'sample::main::hbbb19855251826d6':
/home/ec2-user/sample/src/main.rs:6: undefined reference to 'av_register_all'
collect2: error: ld returned 1 exit status
The required static libraries, libavformat.a and friends, are found in the target/build/debug folder, showing that ffmpeg-sys successfully compiled the libraries.
Here's the rustc command that is failing:
Caused by: process didn't exit successfully: 'rustc --crate-name
sample src/main.rs --crate-type bin --emit=dep-info,link -C
debuginfo=2 -C metadata=250bf40eb277d05a -C
extra-filename=-250bf40eb277d05a --out-dir
/home/ec2-user/sample/target/debug/deps -C
incremental=/home/ec2-user/sample/target/debug/incremental -L
dependency=/home/ec2-user/sample/target/debug/deps --extern
ffmpeg_sys=/home/ec2-user/sample/target/debug/deps/libffmpeg_sys-fa3ff87f80f2d27e.rlib
-L native=/home/ec2-user/sample/target/debug/build/ffmpeg-sys-0b3c813f29a9a20e/out/dist/lib'
(exit code: 1)
libffmpeg_sys-fa3ff87f80f2d27e.rlib is 207M and I assume therefore contains all the statically compiled ffmpeg code.
This only happens when I build on an Amazon Linux instance. Compiling on my regular Fedora 28 desktop results in a working binary.
How would I go about figuring out the root cause of this error?
I solved this problem by building llvm 6.0.1 and then rebuilding with LIBCLANG_PATH set to point to the newer version.
It would appear that rustc has a minimum version requirement on libclang.so, but I could not find an official source documenting that. The version installed on amazon-linux is 3.6.2 which is evidently too old.

Resources