Change approach for native and cross-compilation with clang++ on FreeBSD

[mqudsi]

Correctly fix C++ compilation w/ clang++ on FreeBSD

When cross compiling, we are forced to emit the `--target=<triple>` compiler
flag, but this can break clang++ C++ builds on FreeBSD if the triple isn't
set to a value that causes clang++ to infer the use of libc++ instead of
libstdc++ (the latter of which does not support C++11 and beyond on FreeBSD).

By manually specifying the usage of `-std=libc++` we avoid the need to know
which version of FreeBSD we are targeting (as we do not have that information
from the rust target triple and cannot infer it from the host as we are
cross-compiling).

Note that we were already specifying a default stdlib value libc++ for
`cpp_link_stdlib` under FreeBSD but that is not sufficient.

There are other solutions that would work when not cross compiling such as
omitting the `--target` altogether, but there's no compelling reason to add more
code if this solution works for both native and cross-compiling cases.

This fix supersedes #788. See relevant discussions in #785 and #788.

(Updated)

[thomcc]

The freebsd change is mostly what I had in mind. But the location of the target==host check will change the behavior for every non-cross scenario is going to break way too much.

I'm sympathetic to your suggestion from the other thread that it's better to error than silently be subtly broken. I don't know that it applies here though — this code isn't exactly new and people have been using it successfully for a while. I think it needs a high degree of motivation to change. That is:

1. I don't see evidence that the behavior at the moment (which essentially always passes --target) is in error. There are cases when we definitely need to do this even when not cross-compiling (It's possible for rustc to think it's targetting the host, and the c compiler to not).

2. This crate is pretty old, and is used in far more configurations than we can possibly have tests for.

   Not to mention I think this will concretely break usage when called from xcodebuild, when using cargo.target.<triple>.runner+qemu (or similar) to run the build script, etc. Perhaps I don't particularly care about such configurations, but this just breaks them for no reason, which is not good.

   While I don't take take the stance that we must keep perfect 100% compatibility with every potential configuration (doing so would effectively freeze changes to cc)... it's better not to cause problems for no reason.

[mqudsi]

That was my original thinking in 785, happy to do the same here. Thanks for reviewing.

[thomcc]

Ah, apologies if I misunderstood. (I should admit I've been a bit distracted by goings on at $dayjob)

[mqudsi]

No worries. My bit about "breaking rather than being subtly wrong" was only in argument to not go with the approach in #788. I support minimizing the impact of any changes to this crate and fully agree with the points you made. I just misunderstood what your recommendation was from the other thread but I'm glad we're on the same page now.

I've updated the branch to just use the -stdlib approach for both native and cross-compiling with no other changes. I've tested that this continues to work for native compilation.

We could omit --target only when native compiling on FreeBSD but I see no reason to add complexity and branchiness to the code if this single workaround handles both native and cross-compiling. We can always revisit that decision if there's evidence of any other issues with this approach, but it should cover the bases.

[thomcc]

Sorry for the delay here.

[mqudsi]

No worries. Thanks for merging!