Description
[I'm not sure where to file this bug, it's an awkward intersection of things]
In order to use c++11, you need to have a target triple targeting at least x86_64-apple-darwin11. If you specify x86_64-apple-darwin (as cargo does), and don't explicitly specify -stdlib=libc++, it will fail with very obscure error messages that individual symbols in c++11 aren't defined. If you do explicitly specify -stdlib=libc++, it will fail with the useful:
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
Either way, if the project being built targeting OSX uses c++11 features, it needs to specify --target=x86_64-apple-darwin11 not x86_64-apple-darwin. Not specifying a target at all also works fine.
It's unclear to me who should be specifying this:
- Cargo doesn't know whether you're going to link against libc++, so shouldn't be making this decision. But maybe it should default to darwin11 unless you specify otherwise, just in case.
- cmake-rs doesn't know whether you're going to link against libc++, so shouldn't be making this decision.
- Individual library writers probably shouldn't have to explicitly write the code to conditionally change the darwin triple any time they use libc++.
Maybe the right answer is to just not set the target triple when compiling for the host target. Maybe cargo should target x86_64-apple-darwin11 by default. Maybe cmake-rs should have a "uses-c++11" boolean or something which you can set to have cmake-rs do the target-twiddling for you. Maybe everyone who uses c++11 and cmake should have to conditionally call .target(...) if the target platform is OSX and they use libc++.
I welcome any thoughts!
I suspect that this is also responsible for #37 - explicitly setting .target("x86_64-apple-darwin11") makes boringssl compile correctly.