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.
/Magnus
