When linking mostly-static Linux binaries, link libstdc++.a explicitly.

[jmillikin-stripe]

This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as g++ with the -static-libstdc++ flag.

Fixes #2840

See envoyproxy/envoy#415 for additional
background and context.

cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)

I'm only doing this in the Linux toolchain because MacOS doesn't do static linking of system libs anyway, and I don't know enough about Windows or FreeBSD to test on those platforms.

[bazel-io]

Can one of the admins verify this patch?

[hlopko]

Did you test this patch? Does it solve your problems? I'm asking because you fixed only the static crosstool that bazel uses to bootstrap itself (and for some tests I think), not the crosstool that is used for user builds (that one is generated by tools/cpp/cc_configure.bzl from tools/cpp/crosstool.tpl), and that doesn't sound like what I assumed you wanted to do.

[jmillikin-stripe]

@mhlopko I tested by editing the Envoy CROSSTOOL to save time, but I guess that wasn't a good idea. Patch updated to edit unix_cc_configure.bzl instead.

Output of ldd before and after the patch:

$ ldd with-bazel-0.7/envoy-static
	linux-vdso.so.1 (0x00007ffd72d4c000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f384b017000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f384ae13000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f384abf5000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f384a8f4000)
	libstdc++.so.6 => /home/john/.opt/gcc-7.2.0/lib64/libstdc++.so.6 (0x00007f384a573000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f384a1c7000)
	/lib64/ld-linux-x86-64.so.2 (0x00005555b52fd000)
	libgcc_s.so.1 => /home/john/.opt/gcc-7.2.0/lib64/libgcc_s.so.1 (0x00007f3849fb1000)

$ ldd with-bazel-patch/envoy-static
	linux-vdso.so.1 (0x00007fff8bec7000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007eff20158000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff1ff54000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff1fd36000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff1fa35000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff1f68a000)
	/lib64/ld-linux-x86-64.so.2 (0x0000562b9709f000)

[jmillikin-stripe]

Ping? Anything else I should be doing here?

[hlopko]

Sorry for the silence. It's looking good, could you write a test for this since I'll be refactoring crosstools soon-ish so I don't break this again accidentally? Get some inspiration from cpp_darwin_integration_test.sh to get a platform specific test setup. Thanks!

[jmillikin-stripe]

OK, test added.

[philwo]

@mhlopko Can we merge this now?

[hlopko]

Waiting for @dslomov review.

[jmillikin-stripe]

Gentle ping, again. The holidays are coming up so if this doesn't get merged in soon then I might not be able to respond to comments until January.

[jmillikin-stripe]

Thanks!

I notice 0.9 already has a baseline. Marcel, Dmitry, could this CL please get cherrypicked into the 0.9 release?

[hlopko]

I'm afraid we cannot pick new features into the existing release, only fixes for regressions are allowed (https://blog.bazel.build/2017/09/27/release-cadence.html). I'm sorry it took me so long to review the pull request.