RFR: JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10

[Patrick Zhang OS]

Ping..

Regards
Patrick

-----Original Message-----
From: net-dev <net-dev-bounces at openjdk.java.net> On Behalf Of Patrick Zhang OS
Sent: Wednesday, February 5, 2020 8:19 PM
To: Chris Hegarty <chris.hegarty at oracle.com>; net-dev <net-dev at openjdk.java.net>
Subject: RE: RFR: JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10

Thanks Chris

I extracted the SCTP code change from the original patch, for net-dev review only. Could you please sponsor this? (I do not have push permission), thanks in advance.

JBS: https://bugs.openjdk.java.net/browse/JDK-8238386
Webrev: http://cr.openjdk.java.net/~qpzhang/8238386/webrev.01/
Test: ran jtreg tier1, jdk built with GCC4.8.5, GCC9, and GCC10, no regression found

Regards
Patrick

-----Original Message-----
From: Chris Hegarty <chris.hegarty at oracle.com>
Sent: Tuesday, December 17, 2019 7:06 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>
Cc: net-dev <net-dev at openjdk.java.net>; OpenJDK <security-dev at openjdk.java.net>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

The changes to the SCTP code seem ok.

-Chris.

> On 17 Dec 2019, at 03:00, Patrick Zhang OS <patrick at os.amperecomputing.com> wrote:
> 
> Thanks Martin.
> 
> Hi net-dev, and/or security-dev Reviewers,
> 
> Please help review and sponsor this patch if acceptable.
> It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10).
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
> Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/
> 
> Regards
> Patrick
> 
> From: Martin Buchholz <martinrb at google.com>
> Sent: Monday, December 16, 2019 10:44 AM
> To: Patrick Zhang OS <patrick at os.amperecomputing.com>; net-dev 
> <net-dev at openjdk.java.net>; OpenJDK <security-dev at openjdk.java.net>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes 
> "multiple definition" link errors
> 
> forwarded to other teams for review.
> 
> On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <patrick at os.amperecomputing.com<mailto: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-com
> mon
> 
> 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