RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

[Patrick Zhang OS]

Hi 

Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks.

JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 
Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/

A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip.

[PATCH] PR85678: Change default to -fno-common
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html 

For example, the error message looks like:
* For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv'
build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status

This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit".

About -fcommon vs -fno-cmmon:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common 

Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'"  can make it work, but it just got things hidden again.

In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors."

Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon"

Regards
Patrick