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

[Martin Buchholz]

forwarded to other teams for review.

On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <
patrick at os.amperecomputing.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20191215/fdac0564/attachment.htm>