Update emscripten installation and user

[tlively]

Updates the Emscripten installation used for CI to match the one used in rust-lang/rust. Also runs tests using the default docker user for Emscripten targets because the user should not change between installation and use of Emscripten.

[rust-highfive]

r? @gnzlbg

(rust_highfive has picked a reviewer for you, use r? to override)

[tlively]

Local testing shows some failures, but it would be great to get ideas from someone who has more context about what is going wrong.

[gnzlbg]

@tlively focus on getting the emscripten build jobs green, I'll manually merge this once those pass (and maybe the style build job as well).

Currently, the emscripten build jobs fail with:

running: "emcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-Wall" "-Wextra" "-o" "/checkout/target/wasm32-unknown-emscripten/debug/build/libc-test-698cbdf0c24e93b3/out/src/cmsg.o" "-c" "src/cmsg.c"

--- stderr


error occurred: Failed to find tool. Is `emcc` installed?

You removed some lines from the docker file, maybe those were in charge of putting emcc at the appropriate path ?

[tlively]

The wasm32 builder is encountering what looks like real errors. @gnzlbg it would be great if you could help me diagnose those. The asmjs builder is erroring out on the link because the asmjs target currently fails when full debug info is requested. I'm working on a rustc patch to fix that, but in the meantime do you know how to lower the debuginfo level in the test build?

[tlively]

Another issue here is ABI mismatches when passing pthread_mutexattr_t and pthread_condattr_t. In C, these are defined to be trivial structs with a single unsigned element, so they are passed directly by value. In Rust they are defined by to byte arrays so they are passed by indirect pointer. This type mismatch is causing linker failures. What is the best way to resolve it?

[Aaron1011]

@tlively: I think you need to mark the Rust definitions with #[repr(transparent)]

[tlively]

It looks like #[repr(transparent)] only works for stripping away the outer type when making ABI considerations. In this case the inner type is also causing the issues because arrays are treated differently from single values. I think I will have to change the types :/.

[gnzlbg]

In Rust they are defined by to byte arrays so they are passed by indirect pointer. This type mismatch is causing linker failures. What is the best way to resolve it?

If C changed its API then we'd need to do so here as well. Usually for types for which this can happen we make the fields private, so that we can change their type without breaking users.

[Aaron1011]

In addition the declaration for some of the pthread types being wrong, the wasm32-unknown-emscripten currently seems to be retrieving wrong values for every single C constant (e.g. bad PR_SET_MM value at byte 0: rust: 35 (0x23) != c 0 (0x0)). It looks like the constant values retrieved from libc by emscripten are getting corrupted somehow.

[gnzlbg]

@Aaron1011 can it be that those constants changed value?

@tlively let me know if you have any specific questions about the failures, I can translate them for you.

[tlively]

@gnzlbg Thanks! I've been very busy with other things recently, but I hope to get back to cleaning up this and other Rust/Emscripten issues before the end of the year. If anyone has any spare cycles to help out with this sooner, that would be much appreciated.

[bors]

☔ The latest upstream changes (presumably #1672) made this pull request unmergeable. Please resolve the merge conflicts.

[tlively]

I'm going to close this because I am not actively working on it. I will get back to it at some point, and please let me know if any user runs into issues with any Emscripten stuff.