Test that targets without a shipping libcore / libstd build properly

[gnzlbg]

This PR tests that libc builds on targets that currently don't ship a libcore/libstd by cross-compiling to them from Linux and MacOSX using Xargo.

This fixes the build on DragonflyBSD (superseeds #1237), Haiku, bitrig, and OpenBSD (superseeds #1259).

cc @asomers @strangelittlemonkey @semarie

[rust-highfive]

@gnzlbg: no appropriate reviewer found, use r? to override

[gnzlbg]

r? @gnzlbg (would be nice if some other people could review this, i'm unsure whether the bitrig fix is ok)

[asomers]

So with this PR, Travis will cross compile OSes like Dragonfly from both Linux and OSX? Isn't that redundant? What coverage does libc gain by cross-compiling from two different hosts?

[gnzlbg]

So with this PR, Travis will cross compile OSes like Dragonfly from both Linux and OSX? Isn't that redundant?

For the targets implemented in this PR, yes. I'm unsure if any of these tier2/tier3 targets can only be targeted by some toolchains, but AFAIK not all toolchains can cross-compile to all targets, e.g., the x86_64-apple-darwin can cross-compile to aarch64-apple-ios but the x86_64-unknown-linux-gnu toolchain cannot (I think, I haven't been able to cross-compile to that).

What coverage does libc gain by cross-compiling from two different hosts?

None I think, it was just easier CI wise to enable this, but I guess I should just enable this for Linux, and if we need something more in the future, then we'll enable it then.

[strangelittlemonkey]

While this builds, it still doesn't pass the tests that were failing in my PR. Would it not make sense to merge my PR and then rebase this on top of it?

[gnzlbg]

Would it not make sense to merge my PR and then rebase this on top of it?

Yes, this only fix the "build" part of it, it does not run the libc-tests on DragonflyBSD.

[gnzlbg]

@asomers I've addresses the issues, thoughts?

[asomers]

@asomers I've addresses the issues, thoughts?

Honestly, no. This is fairly far outside of my area of expertise.

[gnzlbg]

Honestly, no.

No thoughts? Or that some of the issues have not been addressed?

[gnzlbg]

cc @alexcrichton could you review this ?

[gnzlbg]

So i've removed the CMSG_ APIs from bitrig since they never compiled correctly, and one would need to add platform-specific code for the platform that must be manually verified.

I'll merge this as soon as CI is green, cc @Susurrus if you want to continue the work with the extra_traits feature, after this PR is merged it should be pretty safe to do so without causing libc to stop compiling in some of the supported platforms.

[alexcrichton]

All looks reasonable to me!

[gnzlbg]

There was some trouble with building the documentation of some of the targets that are built with xargo, but now that's all fixed. I initially used xargo to build the docs of all targets, but that made the documentation bot take over 50 min. The last commit uses cargo to build the docs, and if that fails, then it tries xargo, dialing the doc bot back to under 15 min.

That's a more general approach that we could use in the "build-only jobs", to avoid having to keep track of which targets can be built with cargo, and which one need cargo, but we can always do that later.

@bors: r+

[bors]

📌 Commit a25a42b has been approved by gnzlbg

[bors]

⌛ Testing commit a25a42b with merge 0fa4388...

[bors]

💥 Test timed out

[gnzlbg]

@bors: retry

[bors]

⌛ Testing commit a25a42b with merge 173aace...

[bors]

💔 Test failed - checks-travis

[gnzlbg]

@bors: retry

[bors]

⌛ Testing commit a25a42b with merge 9b708a2...

[bors]

💔 Test failed - checks-travis

[gnzlbg]

@bors: retry

[bors]

⌛ Testing commit a25a42b with merge 5cefa3a...

[bors]

💔 Test failed - checks-cirrus

[bors]

☀️ Test successful - checks-cirrus, checks-travis, status-appveyor
Approved by: gnzlbg
Pushing 5cefa3a to master...