[jdk8u-dev] RFR: 8281096: Flags introduced by configure script are not passed to ADLC build [v6]

Andrew John Hughes andrew at openjdk.org
Thu May 23 00:29:08 UTC 2024


On Wed, 22 May 2024 21:26:32 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> The 8u configure script defines compiler flags in `EXTRA_CFLAGS`, `EXTRA_LDFLAGS` and `EXTRA_ASFLAGS`. Some are added by configure tests, while others are taken directly from corresponding options passed by the user.
>> 
>> 8u still use the legacy HotSpot build system which is not fully integrated with the autoconf system. Variables defined by configure thus have to be explicitly passed down to the separate HotSpot build.
>> 
>> ADLC is a tool used at build-time and so the flags it uses don't impact on the end product. So, for a long time, it has been ignoring these flags defined by configure and using just its own minimal set.
>> 
>> However, with newer compilers, this means that the code is compiled to a newer version of the C++ standard, as the default has changed in GCC 6 and later (see [JDK-8151841](https://bugs.openjdk.org/browse/JDK-8151841)). With the latest versions of GCC (11 and 12), this actually leads to build failures due to the use of 'register' (GCC 11) and the way comments are used (GCC 12) in the code.
>> 
>> We should fix the ADLC build to use the same flags as the rest of the build. The impact should be negligible, given the same flags are already used in the code that is actually shipped.
>> 
>> This does not affect 9+ where HotSpot's build system has been replaced with full integration in the autoconf system.
>> 
>> With this change, 8u can be built with GCC 11 on GNU/Linux. I'd appreciate testing on other platforms, particularly those not covered by GHA (Solaris, AIX - @adamfarley, @sxa & @deepa181 who have provided previous fixes for these platforms)
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Separate host and target compiler flags
>  - Merge remote-tracking branch 'dev/master' into JDK-8281096
>  - Print spec files in right workflow and use path to build directory
>  - Fix whitespace in yaml file
>  - Merge remote-tracking branch 'dev/master' into JDK-8281096
>  - Print the spec.gmk and hotspot-spec.gmk files
>  - Temporarily enable debug logging for cross-compile build
>  - 8281096: Flags introduced by configure script are not passed to ADLC build

I've rewritten the patch so it now uses `HOST_CFLAGS` and `HOST_LDFLAGS` in the ADLC build. These are created in `configure` by not including the `sysroot` arguments.

The below shows the old and new flags in the aarch64 cross-compile, which now passes:

~~~
# Retain EXTRA_{CFLAGS,CXXFLAGS,LDFLAGS,ASFLAGS} for the target flags to
# maintain compatibility with the existing Makefiles
EXTRA_CFLAGS= --sysroot="/home/runner/sysroot-arm64/" -fstack-protector  $(NO_DELETE_NULL_POINTER_CHECKS_CFLAG) \
				    $(NO_LIFETIME_DSE_CFLAG) $(CXXSTD_CXXFLAG)
EXTRA_CXXFLAGS= --sysroot="/home/runner/sysroot-arm64/" -fstack-protector 
EXTRA_LDFLAGS= --sysroot="/home/runner/sysroot-arm64/" -Wl,-z,relro 
EXTRA_ASFLAGS=
# Define an equivalent set for the host flags (i.e. without sysroot options)
HOST_CFLAGS= -fstack-protector  $(NO_DELETE_NULL_POINTER_CHECKS_CFLAG) \
				 $(NO_LIFETIME_DSE_CFLAG) $(CXXSTD_CXXFLAG)
HOST_CXXFLAGS= -fstack-protector 
HOST_LDFLAGS= -Wl,-z,relro
HOST_ASFLAGS=
~~~

I'll remove the verbose build log now, but leave the printing of the spec files as I think it does no harm and may be useful for future debugging.

The remaining failures are due to download issues (Debian Buster release on some architectures, Windows VS2010) and the cacerts tests, both of which are not caused by this patch. It may be worth trying to bump the cross-compile to a later Debian release in another PR, as Buster is about to go EOL.

-------------

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/357#issuecomment-2125984382


More information about the jdk8u-dev mailing list