Use emar instead of ar when building for wasm32

[kornelski]

Static libraries created by the cc crate fail to link in WASM projects with an error:

archive has no index; run ranlib to add one

This is due to use of native ar instead of WASM-aware emar.

[alexcrichton]

I'm not sure that this is quite right, though, since Emscripten is not necessarily installed when compiling for wasm32. What target are you interested in for your project here?

[kornelski]

I guess you're right. On second thought that's a cover-up for a user error. I've meant to "fix" a build for wasm32-unknown-unknown target built with emscripten, where CC=emar, but AR is unset.

I've noticed there's wasm32-unknown-emscripten, so that should be used instead.

So maybe a different approach - could the cc crate detect this mistake and emit a warning? I'm concerned that "archive has no index; run ranlib to add one" is an unfriendly error, and to make things worse, the error message from the linker gives misleading advice (it's a problem of incompatible ar, not missing ranlib).

How about emitting cargo:warning when CC=emcc, but target is wasm32-unknown-unknown? Suggest using wasm32-unknown-emscripten instead.

[alexcrichton]

I'm a little wary to do that, but I'm with you in that I wish we could do something like that. This crate in general does nothing to try to improve error messages from the C compiler, you generally just have to be "in the know" of what to do as a result. (and C error messages, especially with toolchain configuration, often have nothing to do with the fix)

My wariness is that at some point this may even be a valid state. For example emcc may have some sort of standalone flag or something like that which emits a raw wasm binary. (this is just making something up). Overall it's really difficult to know what the underlying toolchain is actually doing and automatically understanding why things went wrong.

I'm not really opposed to doing so but I wanted to point out that this isn't something we do for any other platform even though we in theory could. It's just really hard since there are so many C toolchains running around with all sorts of different requirements/targets/etc.

[kornelski]

OK, it's not a can of worms I'd like to open, so I'll leave it as-is.