ninja/mac: Don't link c-file-only targets to libstdc++

ninja/posix: Don't link c-file-only targets to libstdc++.

The most important part of this change is that LINK will now default to what
is set for CXX (in make) or what is set for CC (in ninja). In ninja, there's
now an additional LINKXX that's set to what CXX is set to, and in ninja
LINKXX is only used to link targets that contain at least one C++ source
file.

Also change several make_global_settings behaviors:

1. The ninja generator was using LD and LD.host for make_global_settings, while
   the make generator uses LINK and LINK.host. Chromium's common.gypi only
   sets the latter, so it looks like this code isn't needed. Removed support
   for setting LD and LD.host via make_global_settings in ninja. (In practice,
   this was alway set to the same thing as CC / CXX anyhow.)
2. The same is done for the environment variables in ninja. Again, as the
   linker now just uses what's set via CC / CXX, this shouldn't be an issue
   in practice.
3. Change the make generator to look at the LINK envvar instead of LD,
   for consistency with its make_global_settings key and with what
   `make -p` prints.

(If setting a linker that's different from CC / CXX is needed later on, this
is easy to add back.)

(Make doesn't have explicit support for setting LINK, make_global_settings
allows changing arbitrary make variables there. But due to the defaults change,
setting LINK is no longer required in make either.)

BUG=chromium:280718

[scottmg, 2013-09-10 21:09:15]

BUG link in description?

lgtm

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
File test/no-cpp/gyptest-no-cpp.py (right):

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:27: def LinksLibStdCpp(p):
nit; p -> path

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:33: o = proc.communicate()[0]
nit; o -> out or output

[Nico, 2013-09-10 21:11:45]

Bug link added, thanks!

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
File test/no-cpp/gyptest-no-cpp.py (right):

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:21: # TODO: Does a test like this make sense with
Windows? Android?
Does msvs automatically link a c++ runtime if there are cc files in a target? or
is that always an explicit setting?

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:27: def LinksLibStdCpp(p):
On 2013/09/10 21:09:15, scottmg wrote:
> nit; p -> path

Done.

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:33: o = proc.communicate()[0]
On 2013/09/10 21:09:15, scottmg wrote:
> nit; o -> out or output

Done.

[Paweł Hajdan Jr., 2013-09-10 21:25:31]

Drive-by with a nit, totally up to you.

https://codereview.chromium.org/23475025/diff/38014/pylib/gyp/generator/ninja.py
File pylib/gyp/generator/ninja.py (right):

https://codereview.chromium.org/23475025/diff/38014/pylib/gyp/generator/ninja...
pylib/gyp/generator/ninja.py:377: self.uses_cpp = False
nit: To avoid possible confusion, I suggest adding a comment there that cpp
means C++, and maybe a brief comment or reference why we want that.

[scottmg, 2013-09-10 21:31:33]

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
File test/no-cpp/gyptest-no-cpp.py (right):

https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
test/no-cpp/gyptest-no-cpp.py:21: # TODO: Does a test like this make sense with
Windows? Android?
On 2013/09/10 21:11:45, Nico wrote:
> Does msvs automatically link a c++ runtime if there are cc files in a target?
or
> is that always an explicit setting?

I'm actually not sure how it decides to depend on msvcp. There's no command line
setting, but just having a .cc file isn't enough. (Or, it might be, but the
linker drops it unless c++ symbols are actually referenced).

[scottmg, 2013-09-10 21:41:39]

On 2013/09/10 21:31:33, scottmg wrote:
>
https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
> File test/no-cpp/gyptest-no-cpp.py (right):
> 
>
https://codereview.chromium.org/23475025/diff/33002/test/no-cpp/gyptest-no-cp...
> test/no-cpp/gyptest-no-cpp.py:21: # TODO: Does a test like this make sense
with
> Windows? Android?
> On 2013/09/10 21:11:45, Nico wrote:
> > Does msvs automatically link a c++ runtime if there are cc files in a
target?
> or
> > is that always an explicit setting?
> 
> I'm actually not sure how it decides to depend on msvcp. There's no command
line
> setting, but just having a .cc file isn't enough. (Or, it might be, but the
> linker drops it unless c++ symbols are actually referenced).

Ah, it's documented, no need to guess apparently.
http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx

"
When you build a release version of your project, one of the basic C run-time
libraries (LIBCMT.LIB, MSVCMRT.LIB, MSVCRT.LIB) is linked by default, depending
on the compiler option you choose (multithreaded, DLL, /clr). If you include one
of the Header Files in your code, a Standard C++ Library will be linked in
automatically by Visual C++ at compile time. For example:

  #include <ios> 
"

There's no magic in the headers that I can see, so I guess the conditions are:
cpp file compiled, and msvcr symbol referenced.

[binji, 2013-09-12 20:46:12]

This change seems to be breaking the mac_sdk_multi bots:

http://build.chromium.org/p/client.nacl.sdk/builders/mac-sdk-multi/builds/589...

AFAICT, the sel_ldr executable only has .c sources, but has dependencies that
have .cc sources. Perhaps this CL is not checking for that case?