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

[Tim Bell]

Erik:

On 09/29/16 00:21, Magnus Ihse Bursie wrote:
> On 2016-09-28 17:42, Erik Joelsson wrote:
>> 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/
>
> Yay! Good riddance... This whole mess was what a friend uses to call "a
> complex non-solution to a simple non-problem". :-)
>
> The fix looks good to me, but the comment
>
>        # Ideally, we should test stdc++ for the BUILD toolchain
> separately. For now
>        # just use the same setting as for the TARGET toolchain.
>
> in the dynamic section does not really makes sense anymore.

Looks good to me as well.

/Tim