Assorted libc-test failures

[japaric]

UPDATE (2016-11-16)

I'm now using (or rather will soon be using) the "one Dockerfile per target" that this repo uses in my smoke repo. See japaric-archived/smoke#32.

I'm now seeing the following errors:

Disclaimer: These builds are 8 days old

• powerpc64le-unknown-linux-gnu. gcc error. I think libc is not testing this target.

• x86_64-unknown-linux-musl. gcc error. Not sure about this one, are we using a different musl version?

All the issues below seem to have been solved.

---

I've been testing, with the help of QEMU, Rust cross compilation targets in this repository (look ma test matrix!). One of tests I'm running is libc-test. I've seen some failures so I figured I should report them here:

• mips-unknown-linux-musl and mipsel-unknown-linux-musl. These targets have legit failures due to wrong bindings and bad constants.
• aarch64-unknown-linux-gnu and powerpc64-unknown-linux-gnu. "error: return from incompatible pointer type [-Werror=incompatible-pointer-types]". The aarch target passes its test in this repository CI, which uses Ubuntu 14.04 (my repository CI uses 16.04). Perhaps is just an innocuous warning that's enabled in gcc-5 but not in gcc-4. UPDATE: This is the same as aarch64 fails with newer glibc (ipc_perm.mode) #231
• i586-unknown-linux-gnu. Seems like ctest doesn't handle the i586 component. But I suppose its definitions must match i686's so there isn't much to test here anyway.
• powerpc-unknown-linux-gnu. Looks like a legit C compilation error.

cc @alexcrichton

[alexcrichton]

Holy cow that is quite the matrix! We've currently got a dockerfile-per-target, so it should be quite easy to add new targets to being tested here. I'd love to get CI up and running for everything here! (nothing is omitted intentionally)

[japaric]

I'm using a single docker image (Dockerfile here) to run all these. Perhaps we can use that image or create one based on it under the rust-lang organization name. (I'm not sure what's the policy on depending on Docker images not owned by the rust-lang organization) When I get the time, I'll see how to integrate my CI scripts with the ones here.

[alexcrichton]

Sounds good to me! I've just preferred lately to have a single target per docker image because it's easy enough to see how to compose them together and otherwise it cuts down the cycle time when debugging one particular target.

[japaric]

I see you forked my docker repository. I want to document one trick I'm using, in case you are
playing with the docker image or thinking about creating a similar one:

• Do not install QEMU on the docker image.
• Instead install qemu-user-static and binfmt-support in a privileged docker container
  (docker run --privileged ..).
• This will let you transparently run "foreign" binaries on the container. IOW, you will be able to directly
  run ./arm-binary or cargo test --target arm-unknown-linux-gnueabi; Instead of having to call
  cargo test --target arm-unknown-linux-gnueabi --no-run && qemu-arm target/debug/arm-unknown-linux-gnueabi/some_test-$HASH. Note that you still have to set QEMU_LD_PREFIX in both cases.

[alexcrichton]

I think we're now testing all these targets, @japaric are there still remaining issues though?

[japaric]

@alexcrichton Everything in my original report seems to be fixed now. I've updated the top comment with two errors I saw in a 8 days old smoke run.

[alexcrichton]

Ah yeah for musl we're installing 1.15 where you're using 1.9 I believe. Those errors are likely benign.

Also holy cow I swear if powerpc64 and powerpc64le are different in terms of APIs I'm going to flip a table. I'll make a PR adding it to this repo though.

[alexcrichton]

Turns out powerpc64le was a bug in ctest. In light of that sounds like we can close!

[japaric]

Turns out powerpc64le was a bug in ctest.

👍 The tables are safe!