[RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

Andrew Hughes gnu.andrew at redhat.com
Thu Jul 7 15:53:06 UTC 2016


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





More information about the build-dev mailing list