GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free:

Commit 390f5b9a authored by chrysn's avatar chrysn
Browse files

Drop GCC workarounds

parent acc6211d
......@@ -65,17 +65,6 @@ fn main() {
.filter(|x| {
match x.as_ref() {
// non-clang flags showing up with arm cortex m3 (eg. stk3700 board)
"-Werror" => false,
"-mno-thumb-interwork" => false,
"-Wformat-overflow" => false,
"-Wformat-truncation" => false,
// non-clang flags showing up for the hifive1 board
"-mcmodel=medlow" => false,
"-msmall-data-limit=8" => false,
"-nostartfiles" => false, // that probably shows up on arm too, but shouldn't matter
"-fno-delete-null-pointer-checks" => false, // seen on an Ubuntu 18.04
// and much more worries on that ubuntu ... maybe just recommend TOOLCHAIN=llvm ?
// Don't pollute the riot-sys source directory
"-MD" => false,
// accept all others
......@@ -156,50 +145,8 @@ static {type_name} init_{macro_name}(void) {{
.expect("failed to write to riot-c2rust.h");
let c2rust_infile;
let c2rust_outfile;
if cc.find("clang") == None {
// Run through preprocessor with platform specific arguments (cf.
// <>)
// This is only done for non-clang setups; those do not need it (and can profit from the
// unexpanded macros). Also, clang does not have "-fdirectives-only' (but their
// "-frewrite-includes" might do as well if it turns out that this *is* needed even there).
let preprocessed_headercopy = out_path.join("riot-c2rust-expanded.h");
let clang_e_args: Vec<_> = cflags
.map(|s| s.clone())
headercopy.to_str().expect("Non-string path for headercopy"),
.expect("Non-string path in preprocessed_headercopy"),
.map(|x| x.to_string()),
let status = std::process::Command::new(cc)
.expect("Preprocessor run failed");
if !status.success() {
"cargo:warning=Preprocessor failed with error code {}, exiting",
c2rust_infile = "riot-c2rust-expanded.h";
c2rust_outfile = "";
} else {
c2rust_infile = "riot-c2rust.h";
c2rust_outfile = "";
let c2rust_infile = "riot-c2rust.h";
let c2rust_outfile = "";
let output = out_path.join(c2rust_outfile);
match std::fs::remove_file(&output) {
// while GCC invoked by RIOT finds the newlib definitions, CLANG does not.
// This workaround fixes the fallout (that each time a *timespec is used, a
// `struct timespec` is generated by bindgen); actual solutions might be
// passing on the CC from the RIOT build system.
struct timespec { char *_unknown;};
// Copied over from newlib's stdatomic.h -- not sure why it's not included, but
// that's currently needed to get mutexes to build.
#include <stdint.h>
typedef _Atomic(int_least16_t) atomic_int_least16_t;
// Workarounds for
// (only needed when building for cortex using toolchain=llvm)
#define UINT16_MAX 0xffff
// When GCC preprocesses the sources on native, it puts a __float128 into the
// max_align_t which clang does not understand.
#define __float128 long double
// This is currently the only relevant user of stdatomic.h. As it doesn't
// access its relevant atomic field from static inlines (and thus from built
// Rust) and forbids users from touching it themselves, we can work around
......@@ -21,7 +21,7 @@
//! `CFLAGS_WITH_MACROS` and `INCLUDES`; both need to be passed in to the Rust
//! build system as a `RIOT_CFLAGS` environment variable.
//! In addition, riot-sys also needs to know the C compiler to properly expand the
//! In addition, riot-sys for some time needed to know the C compiler to properly expand the
//! header files before transpilation; that information is passed in `RIOT_CC`.
//! When using riot-sys, it is usually easiest to run from a target within the Make
......@@ -41,6 +41,7 @@
//! The `RIOT_CC` and `RIOT_CFLAGS` are made available to dependent modules through
//! Cargo; see [riot-wrappers]'s for an example.
//! ## Transition to compile-commands
//! As an alternative to passing `RIOT_CFLAGS` and `RIOT_CC`, the path to a
//! compile-commands.json file can be passed in `RIOT_COMPILE_COMMANDS_JSON`, with
......@@ -50,6 +51,11 @@
//! passed down to dependent crates as they were before. (The passed down CC will just always be
//! clang).
//! In the course of this transition, workarounds for GCC CFLAGS have been removed from riot-sys.
//! Thus, you'll either have to pick `TOOLCHAIN=llvm` for thw whole build, or use the
//! `RIOT_COMPILE_COMMANDS_JSON` mechanism (with a recent enough RIOT version to support it) that
//! produces working CFLAGS even when GCC is used as the main C compiler.
//! ## Extension
//! Currently, only a subset of all the RIOT headers is processed; all the relevant
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment