[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 hotspot-dev
mailing list