Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Thanks for the review Chris. For the record, here’s the updated webrev: http://cr.openjdk.java.net/~vinnie/8027567/webrev.01/ On 30 Oct 2013, at 16:57, Chris Hegarty wrote: > The source changes look fine to me, I'm happy to be listed as a reviewer for > this. ( generated-configure.sh, I just assume is ok once > common/autoconf/autogen.sh is run ). > > -Chris. > > On 30/10/2013 16:24, Vincent Ryan wrote: >> Sure. I’ll re-run autogen.sh and submit an updated webrev. >> Thanks. >> >> >> On 30 Oct 2013, at 16:15, Erik Joelsson wrote: >> >>> I'm leaving for the day pretty soon, so feel free to push this to tl if you >>> have time. >>> >>> If you do, don't forget to run common/autoconf/autogen.sh and to also >>> submit the closed generated-configure. >>> >>> /Erik >>> >>> On 2013-10-30 17:07, Vincent Ryan wrote: Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00, Erik Joelsson wrote: > I found a solution that's also more readable. Posting inline since it's > so small a change: > > diff -r 4f2011496393 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 > +++ b/common/autoconf/basics.m4 > @@ -514,7 +514,7 @@ > if test "x$IS_GNU_MAKE" = x; then > AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, > this is not GNU Make. Ignoring.]) > else > - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP > '\(3\.8[[12]]\)\|\(4\.\)'` > + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' > -e '4\.'` > if test "x$IS_MODERN_MAKE" = x; then > AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is > not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) > else > > /Erik > > On 2013-10-30 16:51, Erik Joelsson wrote: >> It seems the problem is with the grep tool used to parse the version >> string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the >> same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works >> better. I will see if I can figure out something that works with both. >> >> /Erik >> >> On 2013-10-30 16:28, Vincent Ryan wrote: >>> Thanks Chris. >>> >>> So reverting to the previous version of builds.m4 will fix this issue >>> on Solaris but will undo >>> the fix for 8026528 on Windows. Maybe Eric can advise. >>> >>> >>> >>> On 30 Oct 2013, at 15:05, Chris Hegarty >>> wrote: >>> Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: > Please review this fix to correct the JDK8 build Configure script. > It reverts a recent change to common/autoconf/basics.m4 that was > causing a build failure on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 > Webrev: http://cr.openjdk.java.net/~vinnie/8027567/ > >>> >>
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
The source changes look fine to me, I'm happy to be listed as a reviewer for this. ( generated-configure.sh, I just assume is ok once common/autoconf/autogen.sh is run ). -Chris. On 30/10/2013 16:24, Vincent Ryan wrote: Sure. I’ll re-run autogen.sh and submit an updated webrev. Thanks. On 30 Oct 2013, at 16:15, Erik Joelsson wrote: I'm leaving for the day pretty soon, so feel free to push this to tl if you have time. If you do, don't forget to run common/autoconf/autogen.sh and to also submit the closed generated-configure. /Erik On 2013-10-30 17:07, Vincent Ryan wrote: Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00, Erik Joelsson wrote: I found a solution that's also more readable. Posting inline since it's so small a change: diff -r 4f2011496393 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 +++ b/common/autoconf/basics.m4 @@ -514,7 +514,7 @@ if test "x$IS_GNU_MAKE" = x; then AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, this is not GNU Make. Ignoring.]) else - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP '\(3\.8[[12]]\)\|\(4\.\)'` + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' -e '4\.'` if test "x$IS_MODERN_MAKE" = x; then AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) else /Erik On 2013-10-30 16:51, Erik Joelsson wrote: It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris but will undo the fix for 8026528 on Windows. Maybe Eric can advise. On 30 Oct 2013, at 15:05, Chris Hegarty wrote: Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Sure. I’ll re-run autogen.sh and submit an updated webrev. Thanks. On 30 Oct 2013, at 16:15, Erik Joelsson wrote: > I'm leaving for the day pretty soon, so feel free to push this to tl if you > have time. > > If you do, don't forget to run common/autoconf/autogen.sh and to also submit > the closed generated-configure. > > /Erik > > On 2013-10-30 17:07, Vincent Ryan wrote: >> Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed >> today. >> Would you like to take ownership of this issue or shall I push your fix to >> TL? >> >> On 30 Oct 2013, at 16:00, Erik Joelsson wrote: >> >>> I found a solution that's also more readable. Posting inline since it's so >>> small a change: >>> >>> diff -r 4f2011496393 common/autoconf/basics.m4 >>> --- a/common/autoconf/basics.m4 >>> +++ b/common/autoconf/basics.m4 >>> @@ -514,7 +514,7 @@ >>> if test "x$IS_GNU_MAKE" = x; then >>> AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, this >>> is not GNU Make. Ignoring.]) >>> else >>> - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP >>> '\(3\.8[[12]]\)\|\(4\.\)'` >>> + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' >>> -e '4\.'` >>> if test "x$IS_MODERN_MAKE" = x; then >>> AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is >>> not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) >>> else >>> >>> /Erik >>> >>> On 2013-10-30 16:51, Erik Joelsson wrote: It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: > Thanks Chris. > > So reverting to the previous version of builds.m4 will fix this issue on > Solaris but will undo > the fix for 8026528 on Windows. Maybe Eric can advise. > > > > On 30 Oct 2013, at 15:05, Chris Hegarty wrote: > >> Hi Vinnie, >> >> I have seen this issue myself, kind of funny ;-) >> >> ... >> configure: Found GNU make at /java/devtools/i386/bin/make, however this >> is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. >> configure: error: Cannot find GNU make 3.81 or newer! Please put it in >> the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. >> configure exiting with result code 1 >> >> I originally thought that the problem was with a bad change in tl, but >> when reviewing your change I noticed that it is as a result of a changes >> that went into jdk8/build [1], and we see it in tl after a sync up with >> master. >> >> I guess we can still resolve the problem in tl, and sync back into >> master, but Erik should ensure that the original issue is still fixed, >> "8026528: [build] configure does not recognize newer make in cygwin" >> >> -Chris. >> >> [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff >> >> On 30/10/2013 14:40, Vincent Ryan wrote: >>> Please review this fix to correct the JDK8 build Configure script. >>> It reverts a recent change to common/autoconf/basics.m4 that was >>> causing a build failure on Solaris. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8027567/ >>> >
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
I'm leaving for the day pretty soon, so feel free to push this to tl if you have time. If you do, don't forget to run common/autoconf/autogen.sh and to also submit the closed generated-configure. /Erik On 2013-10-30 17:07, Vincent Ryan wrote: Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00, Erik Joelsson wrote: I found a solution that's also more readable. Posting inline since it's so small a change: diff -r 4f2011496393 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 +++ b/common/autoconf/basics.m4 @@ -514,7 +514,7 @@ if test "x$IS_GNU_MAKE" = x; then AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, this is not GNU Make. Ignoring.]) else - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP '\(3\.8[[12]]\)\|\(4\.\)'` + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' -e '4\.'` if test "x$IS_MODERN_MAKE" = x; then AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) else /Erik On 2013-10-30 16:51, Erik Joelsson wrote: It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris but will undo the fix for 8026528 on Windows. Maybe Eric can advise. On 30 Oct 2013, at 15:05, Chris Hegarty wrote: Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00, Erik Joelsson wrote: > I found a solution that's also more readable. Posting inline since it's so > small a change: > > diff -r 4f2011496393 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 > +++ b/common/autoconf/basics.m4 > @@ -514,7 +514,7 @@ > if test "x$IS_GNU_MAKE" = x; then > AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, this > is not GNU Make. Ignoring.]) > else > - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP > '\(3\.8[[12]]\)\|\(4\.\)'` > + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' -e > '4\.'` > if test "x$IS_MODERN_MAKE" = x; then > AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is not > version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) > else > > /Erik > > On 2013-10-30 16:51, Erik Joelsson wrote: >> It seems the problem is with the grep tool used to parse the version string. >> /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu >> grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if >> I can figure out something that works with both. >> >> /Erik >> >> On 2013-10-30 16:28, Vincent Ryan wrote: >>> Thanks Chris. >>> >>> So reverting to the previous version of builds.m4 will fix this issue on >>> Solaris but will undo >>> the fix for 8026528 on Windows. Maybe Eric can advise. >>> >>> >>> >>> On 30 Oct 2013, at 15:05, Chris Hegarty wrote: >>> Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: > Please review this fix to correct the JDK8 build Configure script. > It reverts a recent change to common/autoconf/basics.m4 that was causing > a build failure on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 > Webrev: http://cr.openjdk.java.net/~vinnie/8027567/ > >> >
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
I found a solution that's also more readable. Posting inline since it's so small a change: diff -r 4f2011496393 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 +++ b/common/autoconf/basics.m4 @@ -514,7 +514,7 @@ if test "x$IS_GNU_MAKE" = x; then AC_MSG_NOTICE([Found potential make at $MAKE_CANDIDATE, however, this is not GNU Make. Ignoring.]) else - IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP '\(3\.8[[12]]\)\|\(4\.\)'` + IS_MODERN_MAKE=`$ECHO $MAKE_VERSION_STRING | $GREP -e '3\.8[[12]]' -e '4\.'` if test "x$IS_MODERN_MAKE" = x; then AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) else /Erik On 2013-10-30 16:51, Erik Joelsson wrote: It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris but will undo the fix for 8026528 on Windows. Maybe Eric can advise. On 30 Oct 2013, at 15:05, Chris Hegarty wrote: Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris but will undo the fix for 8026528 on Windows. Maybe Eric can advise. On 30 Oct 2013, at 15:05, Chris Hegarty wrote: Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris but will undo the fix for 8026528 on Windows. Maybe Eric can advise. On 30 Oct 2013, at 15:05, Chris Hegarty wrote: > Hi Vinnie, > > I have seen this issue myself, kind of funny ;-) > > ... > configure: Found GNU make at /java/devtools/i386/bin/make, however this is > not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. > configure: error: Cannot find GNU make 3.81 or newer! Please put it in the > path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. > configure exiting with result code 1 > > I originally thought that the problem was with a bad change in tl, but when > reviewing your change I noticed that it is as a result of a changes that went > into jdk8/build [1], and we see it in tl after a sync up with master. > > I guess we can still resolve the problem in tl, and sync back into master, > but Erik should ensure that the original issue is still fixed, "8026528: > [build] configure does not recognize newer make in cygwin" > > -Chris. > > [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff > > On 30/10/2013 14:40, Vincent Ryan wrote: >> Please review this fix to correct the JDK8 build Configure script. >> It reverts a recent change to common/autoconf/basics.m4 that was causing a >> build failure on Solaris. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 >> Webrev: http://cr.openjdk.java.net/~vinnie/8027567/ >>
Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Hi Vinnie, I have seen this issue myself, kind of funny ;-) ... configure: Found GNU make at /java/devtools/i386/bin/make, however this is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring. configure: error: Cannot find GNU make 3.81 or newer! Please put it in the path, or add e.g. MAKE=/opt/gmake3.81/make as argument to configure. configure exiting with result code 1 I originally thought that the problem was with a bad change in tl, but when reviewing your change I noticed that it is as a result of a changes that went into jdk8/build [1], and we see it in tl after a sync up with master. I guess we can still resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, "8026528: [build] configure does not recognize newer make in cygwin" -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote: Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
[8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected
Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
