arm-linux-androideabi build fails (sched, unistd, signal)

[posborne]

With the new test infrastructure (still being stabilized):

$ DOCKER_IMAGE=rust-cross-android RUST_TARGETS=arm-linux-androideabi RUST_VERSIONS=1.7.0 ./ci/run-all.sh
=======================================================
TESTING VERSION: 1.7.0, TARGET: arm-linux-androideabi
=======================================================
...
     Running `rustc /root/.multirust/toolchains/1.7.0/cargo/registry/src/git.luolix.top-88ac128001ac3a9a/rand-0.3.14/src/lib.rs --crate-name rand --crate-type lib -g -C metadata=6fab17fc670a2bc8 -C extra-filename=-6fab17fc670a2bc8 --out-dir /build/arm-linux-androideabi/debug/deps --emit=dep-info,link --target arm-linux-androideabi -C linker=arm-linux-androideabi-gcc -L dependency=/build/arm-linux-androideabi/debug/deps -L dependency=/build/arm-linux-androideabi/debug/deps --extern libc=/build/arm-linux-androideabi/debug/deps/liblibc-c1044b0a546bbfd6.rlib --cap-lints allow`
/source/src/sched.rs:29:38: 29:56 error: unresolved name `libc::CLONE_NEWUTS` [E0425]
/source/src/sched.rs:29         const CLONE_NEWUTS         = libc::CLONE_NEWUTS as c_int,
                                                             ^~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:29:38: 29:56 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/sched.rs:30:38: 30:56 error: unresolved name `libc::CLONE_NEWIPC` [E0425]
/source/src/sched.rs:30         const CLONE_NEWIPC         = libc::CLONE_NEWIPC as c_int,
                                                             ^~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:30:38: 30:56 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/sched.rs:31:38: 31:57 error: unresolved name `libc::CLONE_NEWUSER` [E0425]
/source/src/sched.rs:31         const CLONE_NEWUSER        = libc::CLONE_NEWUSER as c_int,
                                                             ^~~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:31:38: 31:57 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/sched.rs:32:38: 32:56 error: unresolved name `libc::CLONE_NEWPID` [E0425]
/source/src/sched.rs:32         const CLONE_NEWPID         = libc::CLONE_NEWPID as c_int,
                                                             ^~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:32:38: 32:56 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/sched.rs:33:38: 33:56 error: unresolved name `libc::CLONE_NEWNET` [E0425]
/source/src/sched.rs:33         const CLONE_NEWNET         = libc::CLONE_NEWNET as c_int,
                                                             ^~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:33:38: 33:56 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/sched.rs:34:38: 34:52 error: unresolved name `libc::CLONE_IO` [E0425]
/source/src/sched.rs:34         const CLONE_IO             = libc::CLONE_IO as c_int,
                                                             ^~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:8:1: 36:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sched.rs:34:38: 34:52 help: run `rustc --explain E0425` to see a detailed explanation
/source/src/unistd.rs:180:24: 180:41 error: unresolved name `libc::sethostname` [E0425]
/source/src/unistd.rs:180     let res = unsafe { libc::sethostname(ptr, len) };
                                                 ^~~~~~~~~~~~~~~~~
/source/src/unistd.rs:180:24: 180:41 help: run `rustc --explain E0425` to see a detailed explanation
     Running `/build/debug/build/nix-test-2ca26930e91b2627/build-script-build`
/source/src/sys/signal.rs:50:30: 50:48 error: mismatched types:
 expected `i32`,
    found `u32` [E0308]
/source/src/sys/signal.rs:50         const SA_NOCLDWAIT = libc::SA_NOCLDWAIT,
                                                          ^~~~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:47:1: 57:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:50:30: 50:48 help: run `rustc --explain E0308` to see a detailed explanation
/source/src/sys/signal.rs:52:30: 52:46 error: mismatched types:
 expected `i32`,
    found `u32` [E0308]
/source/src/sys/signal.rs:52         const SA_ONSTACK   = libc::SA_ONSTACK,
                                                          ^~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:47:1: 57:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:52:30: 52:46 help: run `rustc --explain E0308` to see a detailed explanation
/source/src/sys/signal.rs:55:30: 55:46 error: mismatched types:
 expected `i32`,
    found `u32` [E0308]
/source/src/sys/signal.rs:55         const SA_SIGINFO   = libc::SA_SIGINFO,
                                                          ^~~~~~~~~~~~~~~~
<bitflags macros>:91:1: 93:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:47:1: 57:2 note: in this expansion of bitflags! (defined in <bitflags macros>)
/source/src/sys/signal.rs:55:30: 55:46 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to 10 previous errors

[fiveop]

Regarding the SA_-flags:

For some reason android uses unsigned values for sigaction flags. They take there own version for 64 bit and the kernel version for 32 bit, which also has a unsigned value.

The linux man page suggests that it might be an int field. Writing that a struct is "defined as something like" what follows is great specification :)

I suggest we introduce a type definition SaFlagsType to distinguish between platforms.

[kamalmarhubi]

Looks like the namespace related CLONE_ flags can be moved up in libc: https://travis-ci.org/kamalmarhubi/libc/jobs/115718664

Opened rust-lang/libc#227

[larsbergstrom]

Per servo/servo#14171 (comment), changes to support Android would unfortunately probably need to go into nix itself instead of being reflected through libstd.

[ndusart]

I cannot compile nix using the target arm-linux-androideabi (beside the mismatched types for the SA_ flags) for some symbols not being defined in libc for that platform.

These are the missing symbols:

• libc::O_DSYNC (src/fcntl.rs:227:39)
• libc::openpty (src/pty.rs:202:15)
• libc::CLONE_NEWCGROUP (src/sched.rs:27:9)
• libc::EPOLLRDHUP (src/sys/epoll.rs:20:9)
• libc::EPOLLWAKEUP (src/sys/epoll.rs:24:9)
• libc::sethostname (src/unistd.rs:518:30)
• libc::setresuid (src/unistd.rs:855:34)
• libc::setresgid (src/unistd.rs:871:34)

I do not know if these symbols are effectively absent from Android headers and if it's an issue in libc or in nix. Should I report it in libc repository ?

Thanks

[asomers]

Those missing symbols are all issues in libc, if the symbols exist at all on Android. You should report it to libc.

[Susurrus]

@ndusart When you post a libc issue, please also link back to this issue from it so we can track it's progress. Thanks!

[roblabla]

So I just looked at the android NDK headers (which should be, AFAIK, the source of truth). The thing is, none of those symbols are defined in android-18, some are defined in android-21, etc... You can find the headers in $ANDROID_NDK_HOME/platforms/android-18/arch-arm/usr/include/

Each android version has a minimum version requirement for the kernel. As new version of android got released, this minimum version has gone up. Which is why on android-21, some of those symbols are defined.

Furthermore, android doesn't use glibc. It uses bionic as a libc. Bionic isn't 100% compatible with glibc. For instance, old versions of bionic (the one included in android-18 at least) don't provide some functions such as openpty.

Now the question is, what's the correct thing to do for libc, and how can nix sidestep the issue. It's worth noting that there is no indication about what version of glibc is the libc crate following, which can cause problems. Furthermore, I'm not sure what forward compatibility guarantees the linux kernel provides though.

In the meantime, maybe we can #[cfg(target_os = "linux")] the culprits out. I'm working on a patch to do just that.

[asomers]

@roblabla libc's current versioning strategy is to write FFI bindings for the OS's most recent version (for Android I think it's 24) and assume that once a symbol is defined, it will never be removed or changed. There are obviously some big problems with that approach (see rust-lang/libc#570 ) but we can't fix it in Nix. The best that we can do is to #[cfg away whatever nix functions use symbols not present in libc's Android bindings. Then, if those symbols are present in Android 24, we can add them to libc. Finally, some of those functions may need runtime support detection, because Rust has no concept of OS versions.

[ndusart]

Thanks for your feedback, I just posted an issue in libc.