RFR: JDK-8160630: libjimage.so and others should link statically to libgcc

[Erik Joelsson]

When linking C++ on Linux, we currently have a clunky construct to 
enforce static linking of libstdc++ and libgcc which looks like this:

-Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic

To make it work, we also change the linker to "gcc" instead of "g++". 
The problem with this construct is that it doesn't work for libgcc, just 
for libstdc++. When linking libjvm.so, we set -static-libgcc to achieve 
static linking. The other C++ libraries in the JDK build are currently 
not being statically linked to libgcc though the intention has clearly 
been to do so. This problem was highlighted in OracleJDK RPM generation 
where a dependency on libgcc was not expected.

In this patch the problem is fixed by removing the construct above and 
replacing it with the flags "-static-libstdc++ -static-libgcc" and by 
restoring g++ as the linker for all C++ libraries. The change should 
only affect builds with static linking. Dynamic linking builds should 
continue to work just as before, though the explicit -lstdc++ has been 
removed in that case since g++ will add it implicitly anyway.

I have run comparison builds and found no significant differences for 
dynamic builds. For static builds, the footprint for the following 
native libraries increased a little bit since they are now linking 
libgcc statically as was intended:

./demo/jvmti/waiters/lib/libwaiters.so
./lib/amd64/libfontmanager.so
./lib/amd64/libjimage.so
./lib/amd64/libnpjp2.so
./lib/amd64/libsunec.so
./lib/amd64/libt2k.so
./lib/amd64/libunpack.so

Bug: https://bugs.openjdk.java.net/browse/JDK-8160630

Webrev: http://cr.openjdk.java.net/~erikj/8160630/webrev.01/

/Erik