-
Bug
-
Resolution: Fixed
-
P3
-
14, 15
-
Tested and verified at an Ampere aarch64 system (CentOS), and a x86 system (Ubuntu) as well.
-
generic
-
linux
A recent GCC patch (will 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"
[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"
- relates to
-
JDK-8238380 java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10
- Resolved
-
JDK-8238386 (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10
- Resolved
-
JDK-8238388 libj2gss/NativeFunc.o "multiple definition" link errors with GCC10
- Resolved