OS X version cfg

[palfrey]

Using xcrun --show-sdk-version I think we can get an accurate version of the current in-use OS X SDK. This is often, but not always equal to the OS version.

Using this, I then fix the NET_RT_MAXID issue I flagged in #981

[rust-highfive]

r? @alexcrichton

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

[palfrey]

Any thoughts @gnzlbg?

[gnzlbg]

If HOST == TARGET then this will work and be correct, the problem is that this will be incorrect if HOST != TARGET. To make this correct, we would have to find out the OS version of the TARGET but right now there is no way to do that.

I think the HOST != TARGET case is not very common for people using the libc crate directly, but it is probably the case that applies when building libstd, which is how a lot of people are obtaining their libc.

Iff we want to allow users to target multiple OSX versions, then I think we have to think this a bit more through:

• we still have no way to tell the OSX version of the target, we would have to somehow pass it as part of the target triple, and we might want to have the default targets still target the last OSX version for convenience
• we would have to test the different OSX on CI - mach supports 5 OSX versions and 5 OSX targets (travis-CI), that's a big increase in CI load. Every time Apple releases a new OSX version, this CI load bumps up significantly. We would probably need to split OSX from libc into a libSystem-sys crate or similar, and include that and re-export it from libc somehow (all of these would need Rust lib team approval, would all need to work with libstd, etc.)
• most people get libc via libstd, so we would need to make sure that libstd builds libc for the OSX version they use

This would be a lot of work to do correctly. For this particular "breaking" change, given all of the above, I think we should just update the constants to the values of the latest version which is what probably most MacOS X users will be using as a HOST and a TARGET (see #1142 ). If we want to do better here by supporting multiple OSX versions, we might end up having the default apple targets targeting the latest OSX version by default for convenience anyways.

[palfrey]

Ok. In this particular case it's broken by Travis not having a 10.14 image yet (and it's taking a while - see travis-ci/travis-ci#10155), but I'll close this PR now.