libc: The thumb* target family (which have newlib libc) are not supported

I have embedded hardware without an OS. I build Rust code for it with --target thumbv7em-none-eabi and this thumbv7em-none-eabi.json file:

{
    "arch": "arm",
    "cpu": "cortex-m4",
    "data-layout": "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64",
    "disable-redzone": true,
    "executables": true,
    "llvm-target": "thumbv7em-none-eabi",
    "morestack": false,
    "os": "none",
    "relocation-model": "static",
    "target-endian": "little",
    "target-pointer-width": "32",
    "no-compiler-rt": true,
    "pre-link-args": [
        "-mcpu=cortex-m4", "-mthumb",
        "-Tlayout.ld"
    ],
    "post-link-args": [
        "-lm", "-lgcc", "-lnosys"
    ]
}

If I add a Cargo dependency on the libc crate and build with this target, I get many build errors. The first and last are below. The entire thing is at https://gist.github.com/anonymous/780fe74b2ae2834fc9c738dbff60acc0

   Compiling libc v0.2.15
error[E0412]: type name `c_char` is undefined or not in scope
   --> /home/simon/tmp/cargo-home/registry/src/github.com-1ecc6299db9ec823/libc-0.2.15/src/lib.rs:153:35
    |
153 |     pub fn fopen(filename: *const c_char,
    |                                   ^^^^^^ undefined or not in scope
    |
    = help: no candidates by the name of `c_char` found in your project; maybe you misspelled the name or forgot to import an external crate?


// Removed: ~4000 more lines


error[E0204]: the trait `Copy` may not be implemented for this type
   --> /home/simon/tmp/cargo-home/registry/src/github.com-1ecc6299db9ec823/libc-0.2.15/src/macros.rs:44:9
    |
44  |         impl ::dox::Copy for $i {}
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ field `rlim_cur` does not implement `Copy`
    | 
   ::: /home/simon/tmp/cargo-home/registry/src/github.com-1ecc6299db9ec823/libc-0.2.15/src/lib.rs
    |
261 | cfg_if! {
    | - in this macro invocation

error: aborting due to 5 previous errors

error: Could not compile `libc`.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 31 (23 by maintainers)

Commits related to this issue

Most upvoted comments

Is there someone tackling this issue ? This is a blocking issue for an embedded project. If it is just defining type aliases I can take care of it

@gbip what’s your use case? If you only need type aliases for the C types (e.g. for bindgen) you can use the cty crate.

libc for bare metal (target_os / target_env = none) targets doesn’t make much sense to me. The libc crate is for programs that link to libc.{a,so} (libc appends -lc to the linker flags) and bare metal programs don’t link to libc.a. If you are not linking to libc.a then none of the bindings in this crate (e.g. fopen) will work. This crate would should up as empty when compiled for target_{os,env} = none.

Supporting arm+newlib for custom targets like the GBA and the DS makes total sense but sounds like a separate issue.

Usually the libc variant corresponds to target_env rather than target_os, so maybe the triple would be thumbv7m-none-newlibeabi?

A first step would be defining c_char and other primitive type aliases for those targets. Even if there isn’t bindings for newlib functions yet, this would already help with FFI. (std::os::raw is not available in core.)