Explore static linking as an approach to "local gcc"

[Paul Hargrove]

In docs/local-gcc.md we describe multiple approaches to dealing with linker paths for libstdc++ (though the same issues arise for libgcc in both C and C++ codes).

Two options not currently mentioned might be worth adding

1. Linking -static-libgcc -static-libstdc++ would likely fix the problem
2. Building gcc with only static versions of its support libs would almost certainly fix the problem

There are known risks associated with fully static linking (we've seen pthread problems, for instance). Before we make any recommendation meant to encourage even partial static linking, we need to test them ourselves.

[Paul Hargrove]

Option 1 works in testing on Summit, where /usr/bin/g++ is 4.8.5.
With the gcc/6.4.0 module loaded I can build and run hello-world from the PG just fine.
Normally, if I unload the gcc environment module, I can no longer run because the necessary entry is gone from LD_LIBRARY_PATH.
However, make hello-world EXTRA_FLAGS='-g -static-libgcc -static-libstdc++' yields an executable that works even when the gcc environment module is unloaded.

Option 2 works in testing on Dirac, where I was able to remove read perms from libstdc++.so.*.
I was concerned that ld might ignore the compiler-specific static lib in favor of the dynamic one in /usr/lib64.
However, that is not the case and the order in the library search path is honored regardless of static/dynamic libs.
I am NOT immediately planning to document this variant on the solution because we've so far avoided providing instructions regarding the actual building and installation of GCC, and because this would impact non-UPC++ codes using the same compiler installation.

Proposed documentation update in PR#104

[Paul Hargrove]

Document partial static linking option

This commit documents -static-libgcc -static-libstdc++ as an additional option for dealing with dynamic library search problems when building one's own g++.

Resolves issue 208

→ <<cset 6e484542a4ce>>