OpenJDK11 build on macOS with autoconf 2.72 / -std=gnu++11 option

[Kim Barrett]

> On Jan 3, 2024, at 7:16 AM, Baesken, Matthias <matthias.baesken at 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!

But I wonder why our explicit -std=gnu++98 (or whatever we were using) doesn't
override that.  In the command lines are you seeing

   "g++ ... -std=gnu++11 ... -std=c++14"

I'm also not sure what will happen with later JDK versions that specify
-std=c++14.

I have no idea why disabling PCH might change things in this area.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240103/ec28bc86/signature.asc>