snip... > > > I'm also now seeing a problem with GCC 6 only that is unique to the > > > latest > > > OpenJDK 9 > > > and what looks like the gtest code. It seems to be the result of the > > > header > > > changes > > > also documented in [0] which were introduced in January [1] (and so > > > probably weren't > > > in earlier test versions of GCC 6). I'm able to work around it and get a > > > completed > > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be > > > something > > > to do with the changes to stdlib.h in GCC 6. Something for a separate > > > bug. > > > > What fun! > > A new batch of changes just came through which seems to have fixed it. > I'm guessing this one: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47 > > Either way, I'm happy I don't have to debug it :-) >
Sadly, I celebrated too soon; it seems that change just delayed the failure until much later in the build. I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp, we have: #ifdef max #undef max #endif #ifdef min #undef min #endif #define max(a,b) Do_not_use_max_use_MAX2_instead #define min(a,b) Do_not_use_min_use_MIN2_instead The problem is that max and min are now longer macros in the GCC 6 C++ library. So they can't be undefined. The build succeeds if I disable (#if 0) the definition of max and min. So we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS needs to be defined to get the old behaviour. I prefer the former. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
