need to test with more OSX versions

[aturon]

Recent changes landed that broke Rust on Mac OS 10.9 (Mavericks) and above, see #17214

The problem is that the linker is being passed an argument that works for gcc, but that clang rejects. (Mac OS moved wholesale to clang in 10.9, it appears.)

Unfortunately, this breakage wasn't caught by bors. Apparently the testing infrastructure is running an older version of Mac OS and therefor using gcc rather than clang.

To avoid surprise Mac OS breakage in the future, we should make sure to test against clang before landing PRs.

cc @brson @kballard @pnkfelix

[alexcrichton]

Note that we do indeed build with clang on all the OSX builders, the gcc version is ancient (4.2) and wouldn't build C++11-required LLVM I believe. That being said, it looks like newer versions of clang made this an error as opposed to an warning:

$ ssh rust-mac6.corp.mtv2.mozilla.com clang -fno-use-linker-plugin foo.c -c
clang: warning: argument unused during compilation: '-fno-use-linker-plugin'

[aturon]

@alexcrichton Thanks. (The gcc/clang thing was just some speculation floating around.)

That being the case, is there anything actionable here?

[alexcrichton]

We could probably benefit from a builder from all OSX versions. I believe we currently only test on 10.7 and 10.8, but we could add a 10.9 builder and make sure they stay up-to-date. Either that or we could test against all Xcode versions which may be the more relevant version in this case.

[alexcrichton]

(tweaked the title a bit)

[lilyball]

Xcode is the more important bit, that's what controls e.g. whether the system actually has GCC installed. Although more recent versions of Xcode do tend to drop support for older versions of the OS (I'm not sure offhand what the OS support is for the most recent stable Xcode).

As soon as it's feasible to do so, it would be good to test on OS X 10.10 though (it's still in beta, which is why I'm not saying it should be tested now, although it certainly could be). This is primarily because it appears that 10.10 has somehow changed the default LDPATH, which causes issues when trying to link against third-party libraries that live in /usr/local/lib (because I can't pass -L /usr/local/lib to rustc or it breaks when trying to find its own libraries as now it finds duplicates). This is documented in #13733.

[brson]

I doubt it's possible but if multiple xcode's can be installed in parallel that would make this easier.

[ghost]

Multiple versions of xcode can be installed and toggled using xcode-select.

[steveklabnik]

Triage: no change here so far.

[pnkfelix]

@freebroccolo doesn't xcode-select change the default xcode system-wide? I had inferred that what brson wanted was to be able to switch in a local manner. ..

(Or maybe it doesn't matter; I don't know enough about how well our build infrastructure is virtualized for Mac hosts)

[brson]

changing xcode system wide would be sufficient if we limited build concurrency to 1

[ghost]

@pnkfelix yes, as far as I remember it does. There may be another way to switch versions nicely that isn't system wide in this fashion but I don't know of it.

[ranma42]

The manpage of xcode-select suggests an alternative to xcode-select --switch:

To set the path without superuser permissions or only for the current shell session, use the DEVELOPER_DIR environment variable instead

[alexcrichton]

Will make a new metabug around this soon