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
- Refactored the modules for bare metals systems to suit the advices provided in #375. — committed to gbip/libc by gbip 6 years ago
@gbip what’s your use case? If you only need type aliases for the C types (e.g. for bindgen) you can use the
ctycrate.libcfor bare metal (target_os / target_env = none) targets doesn’t make much sense to me. Thelibccrate is for programs that link to libc.{a,so} (libcappends-lcto 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_envrather thantarget_os, so maybe the triple would bethumbv7m-none-newlibeabi?A first step would be defining
c_charand 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::rawis not available incore.)