On 1/3/24 13:03, Kim Barrett wrote:
On Jan 3, 2024, at 7:16 AM, Baesken, Matthias <matthias.baes...@sap.com> wrote:
Btw. I found this rather recent discussion about reverting the forcing
of setting -std=gnu++11 in autoconf :
https://urldefense.com/v3/__https://mail.gnu.org/archive/html/bug-autoconf/2023-12/msg00073.html__;!!ACWV5N9M2RV99hQ!KfFeVOARPmr8RlTN3t2qMgkljzWkcpqA_NwxnyMtkaHzz3dwDxZjVsZZZvQLEXP-Rd6rngZKnovzj0C6Uzn-XF_4Gw$
https://urldefense.com/v3/__https://savannah.gnu.org/support/?110879__;!!ACWV5N9M2RV99hQ!KfFeVOARPmr8RlTN3t2qMgkljzWkcpqA_NwxnyMtkaHzz3dwDxZjVsZZZvQLEXP-Rd6rngZKnovzj0C6Uzk4Umn7ug$
revert forcing/setting -std=gnu++11 by default (introduced in Autoconf 2.70)
So autoconf forcibly selects a -std= option, possibly overriding either an
explicit option or the compiler's default. Who thought that was a good idea?
There are even comments from the time that question that "feature".
It looks like there is code to attempt to deal with that sort of thing in our
build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4. That
dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The
AC_PROG_CC/CXX feature affects the CC/CXX variables. Bleh!
Looks like we need to extend this functionality and filter out any
"-std*" flags added by autoconf from CC/CXX. Even if later "-std=c++14"
on the command line overrides correctly, it would be good for
sanitation. I think such a fix should be done in mainline to avoid
different behavior with different versions of autoconf. It can then be
backported to openjdk 11 to fix the more severe issue described here.
/Erik
