The changes to the SCTP code seem ok. -Chris.
> On 17 Dec 2019, at 03:00, Patrick Zhang OS <patr...@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 <marti...@google.com> > Sent: Monday, December 16, 2019 10:44 AM > To: Patrick Zhang OS <patr...@os.amperecomputing.com>; net-dev > <net-dev@openjdk.java.net>; OpenJDK <security-...@openjdk.java.net> > Cc: core-libs-dev <core-libs-...@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 > <patr...@os.amperecomputing.com<mailto:patr...@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
