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

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Sep 29 07:21:37 UTC 2016

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.


More information about the build-dev mailing list