rustc LTO bitcode incompatible with clang LTO bitcode files by default on OS X

[froydnj]

(Somewhat related to #57438)

In trying to turn on cross-language LTO in Firefox for all of our supported targets, we discovered that clang --target=X doesn't necessarily tag the generated bitcode files as belonging to target X on OS X. The Darwin driver for clang will compute an OS-specific (ios, macosx, etc.) and version-specific (macosx10.9.0, etc.) triple based on things like MACOSX_DEPLOYMENT_TARGET and the particular SDK in use. See for example:

https://github.com/llvm-mirror/clang/blob/cda3d286934fcc7de3687bb8a178947a8266d1f8/lib/Driver/ToolChains/Darwin.cpp#L1598-L1761
https://github.com/llvm-mirror/clang/blob/cda3d286934fcc7de3687bb8a178947a8266d1f8/lib/Driver/ToolChains/Darwin.cpp#L828-L850

So if you are using clang --target=x86_64-apple-darwin and rustc --target=x86_64-apple-darwin in your build system, you'll still get bitcode files that ThinLTO will refuse to link together. This is not a great experience by default. I assume the same would be true when compiling for iOS.

It can be worked around on the C/C++ side of things (clang --target=X ... -Xclang -triple -Xclang x86_64-apple-darwin, where the -Xclang options override the driver magic above), but it would be nice if rustc somehow did the right thing by default. At minimum, I think supporting MACOSX_DEPLOYMENT_TARGET (and others?) and something to determine a more specific OS for the triple than darwin would be good; I'm less certain that groveling around in the SDK is a good thing, especially since rustc doesn't need the SDK in the same way clang does.

cc @michaelwoerister

[michaelwoerister]

cc @rust-lang/compiler, and some people who might have experience with target triple handling: @alexcrichton @nikic @japaric @joshtriplett @rust-lang/cargo

[froydnj]

It's worth noting that my claimed workaround on the C/C++ side does not work for nontrivial programs (e.g. a plain x86_64-apple-darwin triple won't be able to use thread-local storage). So there's no good way to make things work at the moment, I think.

[alexcrichton]

We should probably just update rustc to match clang in this regard, dynamically telling LLVM about the more precise target triple with version information.

[michaelwoerister]

@alexcrichton Would you say that's generally in line with what people can expect, i.e. that the actual target triple can be more specific than the specified one? (Clang seems to do just that)

[alexcrichton]

Oh heh I have no idea what people generally expect from a target triple level, I was just coming from a general expectation that clang/rustc match and do roughly the same thing where possible. I'm not actually sure what effect the target has on either LLVM or the linker. It's probably something subtle somewhere which matters, but no one may be coming across it in Rust yet

[froydnj]

I am attempting to write patches for this.

[metajack]

This seems somewhat related to #35968.