Commits on May 13, 2019

1. default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targets …

   Over in rust-lang#60378, we made `rustc` switch LLVM target triples dynamically
   based on the `MACOSX_DEPLOYMENT_TARGET` environment variable.  This
   change was made to align with `clang`'s behavior, and therefore make
   cross-language LTO feasible on OS X.  Otherwise, `rustc` would produce
   LLVM bitcode files with a target triple of `x86_64-apple-darwin`,
   `clang` would produce LLVM bitcode files with a target triple of
   `x86_64-apple-macosx$VERSION`, and the linker would complain.
   
   This change worked fine, except for one corner case: if you didn't have
   `MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust
   code, you'd get warning messages similar to:
   
   ```
   warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin'
   ```
   
   This message occurs because libstd is compiled with
   `MACOSX_DEPLOYMENT_TARGET` set to 10.7.  The LLVM bitcode distributed in
   libstd's rlibs, then, is tagged with the target triple of
   `x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for
   "user" code is tagged with the target triple of `x86_64-apple-darwin`.
   
   It's not good to have LTO on just Rust code (probably much more common
   than cross-language LTO) warn by default.  These warnings also break
   Cargo's testsuite.
   
   This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was
   set to 10.7.  "user" code will then be given a target triple that is
   equivalent to the target triple libstd bitcode is already using.  The
   above warning will therefore go away.
   
   `rustc` already assumes that compiling without
   `MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target
   compatible with OS X 10.7 (e.g. that things like TLS work properly).  So
   this change is really just making things conform more closely to the
   status quo.
   
   (It's also worth noting that before and after this patch, compiling with
   `MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target
   triples with an "apple" version ignore OS versions when checking
   compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just
   fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)

   

   froydnj committed May 13, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for 7e94f9c
   • Browse repository at this point

   Copy the full SHA

   7e94f9c View commit details

   Browse the repository at this point in the history