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

[Andrew Hughes]

snip...

> >> 
> >> What I'm worried about is that by keeping those checks we might get
> >> and use the wrong answer in some cases where the BUILD and TARGET
> >> compilers are of different vintage. Maybe that will just encourage
> >> someone to fix them...
> > 
> > Thanks. I agree it's an issue. I just don't think I'm the right person
> > to undertake rewiring all that, as I've never even used the
> > cross-compilation
> > support so far.
> 
> Yeah, I feel the same way.  While I've dealt with cross-compilation
> issues of this sort enough to recognize the presence of problems, that
> work wasn't with this build system.
> 
> > Do you know if there's already a bug for this? If not, I'll file one.
> 
> I didn't find any relevant bugs.
> 

I've filed one: https://bugs.openjdk.java.net/browse/JDK-8160926

snip...

> 
> > Revised webrevs:
> > 
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot
> 
> These look good to me.
> 

Thanks.

I need someone at Oracle to push this one through, as the
configure script for the closed code needs regenerating too. Apparently,
I broke things last time :(

> > 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 :-)

> 
> > [0] https://gcc.gnu.org/gcc-6/porting_to.html
> > [1]
> > https://github.com/gcc-mirror/gcc/commit/6c8ced3f4f867b72a623fe2f23efa204c5786a28
> > --
> > 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
> 
> 
> 

Thanks for the great feedback on this patch,
-- 
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

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

[Kim Barrett]

> On Jul 6, 2016, at 1:23 AM, Andrew Hughes  wrote:
> 
> - Original Message -
>>> On Jul 5, 2016, at 1:33 PM, Andrew Hughes  wrote:
>>> 
>>> - Original Message -
> On Jul 5, 2016, at 11:22 AM, Andrew Hughes  wrote:
 common/autoconf/flags.m4
 716 $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}"
 
 There is a pre-existing bug in the setup of ${$2CXXSTD_CXXFLAG}.  It
 is using FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, which doesn't know about
 the BUILD/TARGET distinction.
>>> 
>>> This seems to be a problem with both FLAGS_C_COMPILER_CHECK_ARGUMENTS
>>> and FLAGS_CXX_COMPILER_CHECK_ARGUMENTS, and thus with the
>>> FLAGS_COMPILER_CHECK_ARGUMENTS macro that calls them both, which are used
>>> in several places. I think this is outside the scope of this patch and
>>> something which should be fixed by completing the current half-hearted
>>> cross-compilation support. My aim here is just to fix the regression
>>> which breaks the GCC 6 support on build==target builds, and I'd rather
>>> whoever was working on the cross-compilation build continued that work.
>>> There is a solution already in the handling of the warning argument
>>> check, but it needs to be generalised to the other cases.
>> 
>> I totally agree that fixing the xxx_CHECK_ARGUMENTS is out of scope
>> for this patch.
>> 
>> What I'm worried about is that by keeping those checks we might get
>> and use the wrong answer in some cases where the BUILD and TARGET
>> compilers are of different vintage. Maybe that will just encourage
>> someone to fix them...
> 
> Thanks. I agree it's an issue. I just don't think I'm the right person
> to undertake rewiring all that, as I've never even used the cross-compilation
> support so far.

Yeah, I feel the same way.  While I've dealt with cross-compilation
issues of this sort enough to recognize the presence of problems, that
work wasn't with this build system.

> Do you know if there's already a bug for this? If not, I'll file one.

I didn't find any relevant bugs.

>> In the specific case of -std=gnu++98, it seems unlikely we'll see such
>> a misconfiguration any time soon. That option was introduced in
>> gcc3.3, and it seems unlikely to me that anyone is building the JDK
>> with such an old compiler (though it wouldn't be the first time I've
>> been surprised in that way). OTOH, if the compiler is very new and has
>> dropped support for that standard (e.g. some as yet not even announced
>> version of gcc), we actually want a build failure, since our code was
>> written for that standard and not some later one. So we're unlikely to
>> be hurt by the use of xxx_CHECK_ARGUMENTS here.
>> 
> 
> I agree it's more likely that gnu++98 is going to be dropped at some point,
> than we had a compiler that doesn't support the -std option. Hopefully,
> making what was an implicit default before now explicit will encourage
> developers to look at moving the code forward to a later version of the
> standard. That's probably something for JDK 10+ though.

I think there is interest in that direction.

>> I think there are some more that are outside of HotSpot.
>> 
>> Searching the build directory for *.o.cmdline files that don’t contain
>> -std=gnu++98, e.g.
>> 
>> find . -name "*.o.cmdline" ! -exec egrep -q -e "-std=gnu\+\+98" {} \; -print
>> | xargs dirname | uniq
>> 
>> produces a lot of stuff in ./support/native, the afore mentioned adlc, and a
>> smattering of others.
>> 
>> I think those might be better addressed by more followups, to get what we’ve
>> got so far in.
> 
> Thanks for the .cmdline trick. I wasn't aware of that.

The .o.cmdline files are a feature of the new build system that I
like a lot.

> The -std=gnu++98 switch is only appropriate for the C++ compiler. Most of the
> support/native object files are C files.
> 
> C++ code is used in the following:
> […]
> Using find . -name "*.o.cmdline" -exec egrep -q -e "g\+\+" {} \; ! -exec 
> egrep -q -e "-std=gnu\+\+98" {} \; -print
> I don't see any remaining files with the latest patch.

Yay!

>> But you will need that fix for JDK-8157358.  I guess I should post an
>> RFR for it... or you can just incorporate it into this patch if I don’t get
>> that RFR done soon.
> 
> I wasn't planning to either, but it was likewise bugging me when I
> was trying to fix the GCC 6 issue. Ironically, it took much longer to
> work out what was going on there than it did to realise I needed to
> add the flags to JVM_CFLAGS :(
> 
> I've included the fix in this patch, assuming that's ok with you.

Yes, that’s fine with me.

> If gcc is not being used, CXXSTD_CXXFLAG won't be set so this should be a 
> safe no-op.

Oh, right.

> Revised webrevs:
> 
> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot

These look good to me.

> I'm also now seeing a problem with GCC 6 only that is unique to the latest 
> 

Error using JIB on linux lab machine

[Gerald Thornbrugh]

Hi Everyone,

I am trying to use JIB to do a build on a linux lab machine 
(sc11137378.us.oracle.com) and get an error during the “make” command.
The “configure” completes without error and when I do the “make” I get an an 
error that seems to related to this message in the output:

error: Bad owner/group: 
/scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/tmp/jre-rpm/SOURCES/jre-9.tar

Below is more of the output:

$ bash common/bin/jib.sh make
[jib LOG] Mirror site main
[jib LOG] Setting up jib 2.0-SNAPSHOT
[jib LOG] jib 2.0-SNAPSHOT already installed
[jib LOG] JDK build wrapper v2.0 bbb0e38ca66c25b2de582eeec1d5968109c9cfb1
[jib LOG] Mirror site main
[jib LOG] Setting up jdk-linux_x64 8u60+1.0
[jib LOG] jdk-linux_x64 8u60+1.0 already installed
[jib LOG] Build ID: 2016-07-06-085727.gthornbr.jdk9
[jib LOG] Build profile: linux-x64
[jib LOG] Build configuration: linux-x64
[jib LOG] Build platform: linux_x64
[jib LOG] Target platform: linux_x64
[jib LOG] Setting up gnumake 4.0+1.0
[jib LOG] gnumake 4.0+1.0 already installed
[jib LOG] Setting up jtreg 4.2
[jib LOG] jtreg 4.2 already installed
[jib LOG] Setting up tonga 4.0.0_May_12_2014+1.0
[jib LOG] tonga 4.0.0_May_12_2014+1.0 already installed
[jib LOG] 
JT_HOME=/var/tmp/jib-gthornbr/install/java/re/jtreg/4.2/promoted/all/b02/bundles/jtreg_bin-4.2.zip/jtreg
[jib LOG] 
TONGA_HOME=/var/tmp/jib-gthornbr/install/jpg/infra/builddeps/tonga/4.0.0_May_12_2014+1.0/tonga-4.0.0_May_12_2014+1.0.zip
[jib LOG] 
/var/tmp/jib-gthornbr/install/jpg/infra/builddeps/gnumake-linux_x64/4.0+1.0/gnumake-linux_x64-4.0+1.0.tar.gz/bin/make
 CONF_NAME=linux-x64 
Building configuration 'linux-x64' (matching CONF_NAME=linux-x64)
.
.
.
<<>>Recursively making ./bundles all @ Wed Jul  6 09:07:28 PDT 2016 ...
make[5]: warning: -jN forced in submake: disabling jobserver mode.
+ uname
+ tr A-Z a-z
+ command -v bash
/scratch/w/gthornbr/JDK-8146598/jdk9/install/make/share/defs/All.gmk:662: Wed 
Jul  6 09:07:28 PDT 2016 <<
+ uname
+ tr A-Z a-z
+ command -v bash
/scratch/w/gthornbr/JDK-8146598/jdk9/install/make/share/defs/All.gmk:662: Wed 
Jul  6 09:07:28 PDT 2016 <<
Sanity check passed.
779448 blocks
ls: cannot access 
/scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/jre/man/man1: No 
such file or directory
ls: cannot access 
/scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/jdk/man/man1: No 
such file or directory
error: Bad owner/group: 
/scratch/w/gthornbr/JDK-8146598/jdk9/build/linux-x64/install/tmp/jre-rpm/SOURCES/jre-9.tar
c
Building for target x86_64-Sun-Linux
Makefile:36: recipe for target 'j2re-rpm' failed
make[6]: *** [j2re-rpm] Error 1
Makefile:16: recipe for target 'all' failed
make[5]: *** [all] Error 2
Makefile:73: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[3]: *** [installer] Error 2
/scratch/w/gthornbr/JDK-8146598/jdk9/install/make/Makefile:104: recipe for 
target 'installer' failed
/scratch/w/gthornbr/JDK-8146598/jdk9/closed/make/Main.gmk:57: recipe for target 
'installer' failed
make[2]: *** [installer] Error 1
make[2]: *** Waiting for unfinished jobs

ERROR: Build failed for target 'default (product-bundles test-bundles 
docs-bundles)' in configuration 'linux-x64' (exit code 2) 
=== Make failure sequence repeated here ===
Makefile:36: recipe for target 'j2re-rpm' failed
Makefile:16: recipe for target 'all' failed
Makefile:73: recipe for target 'all' failed
/scratch/w/gthornbr/JDK-8146598/jdk9/install/make/Makefile:104: recipe for 
target 'installer' failed
/scratch/w/gthornbr/JDK-8146598/jdk9/closed/make/Main.gmk:57: recipe for target 
'installer' failed
=== End of repeated output ===
Hint: Try searching the build log for the name of the first failed target.
Hint: If caused by a warning, try configure --disable-warnings-as-errors.

/scratch/w/gthornbr/JDK-8146598/jdk9/make/Init.gmk:286: recipe for target 
'main' failed
make[1]: *** [main] Error 1
/scratch/w/gthornbr/JDK-8146598/jdk9/make/Init.gmk:185: recipe for target 
'default' failed
make: *** [default] Error 2

Below is the “name -a” from sc11137378.us.oracle.com 
:

$ uname -a
Linux sc11137378 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux


Has anyone seen a failure like this?

What am I doing wrong?

Is the configuration of sc1113738.us.oracle.com 
 missconfigured or not supported by JIB?

Thanks!

Jerry