Hi Volker, This will still not work on msys.
While it would be an improvement to check for OPENJDK_TARGET_OS_ENV = windows.cygwin instead (or similar, I don't have source code access at the moment), this would still leave msys out in the cold. I think it's a bit unfortunate to cause msys to break even further. I have no easy suggestion on how to fix this in msys however, so an AC_MSG_ERROR for windows.msys might be better than nothing. Then at least the missing implementation becomes visible. You can push multi-repo fixes with a single bug number. I do that all the time. If your stage forest does not have a closed counterpart (which I doubt), then you can push this yourself. An autoconf update will be needed when the stage forest is integrated into a forest which has a closed counterpart, but only then, and that is the work of the person doing the integration. /Magnus > 18 nov 2013 kl. 17:34 skrev Volker Simonis <volker.simo...@gmail.com>: > > Hi, > > here's a new version of the webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8026964.v2/ > > I now use '-XshowSettings:properties' as suggested by Kumar, but not > '-version'. This is because '-XshowSettings' didn't work together with > '-version' before 7u6 (see "7123582 : (launcher) display the -version > and -XshowSettings", > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123582). > > I know that the official build README mentions 7u7 as the minimum boot > JDK but as this change is also about non OpenJDK/Oracle boot JDKs I > prefer to be conservative here (and actually the few more lines that > must be parsed by AWK don't really make a difference here). > > I've also did yet another small change for the Windows case: I convert > the content of sun.boot.class.path to Unix form, but with Windows path > separators. This is required by the FIXPATH utility which will convert > it back to the Windows form later on during the build process. > > And unfortunately this change also requires another tiny change in > jdk/makefiles/Setup.gmk - and all just to make the Windows build > happy:( We now have to quote BOOT_RTJAR with double quotes in > jdk/makefiles/Setup.gmk (as this is already done for the Corba make) > because it is a path list now and not just a single file: > > http://cr.openjdk.java.net/~simonis/webrevs/8026964.jdk/ > > I think we must push the jdk-change first, because it will do no harm > with the current BOOT_RTJAR settings. Afterwards, we can safely push > the configure change in the root repository. I'm only not sure if I > need a new Bug-ID for the JDK change because there have been different > statements regarding such multi-repo changes in the past. > > And I suppose I can't push these changes myself even to stage, because > they require the re-generation of the closed auto-generated config > script. So I need your help... > > Thank you and best regards, > Volker > > On Fri, Nov 15, 2013 at 6:51 PM, Kumar Srinivasan > <kumar.x.sriniva...@oracle.com> wrote: >> >> Hi Volker, >> >> One thing I notieced, >> >> BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 ....... >> >> I suggest using java -XshowSettings:props -version 2>&1 ......... >> >> props, will narrow down the reporting to only properties section, which is >> really what you want >> >> -version, will allow the launcher to return a 0 exit value, since >> -XshowSettings >> behaves like -showversion ie. another class or option is expected for the >> launcher >> to continue. >> >> Kumar >> >> >> >>> Hi, >>> >>> could you please review the following small webrev: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8026964/ >>> >>> It not only fixes bug 8026964 on AIX, but is changes the general way >>> of how to compute BOOT_RTJAR. >>> >>> With the new solution, BOOT_RTJAR is computed right from the system >>> property 'sun.boot.class.path'. The new solution should be more robust >>> and more portable as it doesn't depend on the name of the jar file >>> which contains the boot classes and it also doesn't depend on the fact >>> that all these classes are located in a single jar file. >>> >>> In order to avoid build warnings, I've taken extra care to remove jar >>> files and paths from the 'sun.boot.class.path' output which do not >>> exist (e.g. jfr.jar is not available in an OpenJDK build but appears >>> in 'sun.boot.class.path' anyway - maybe this is another bug that >>> should be fixed; also jre/classes appears in 'sun.boot.class.path' >>> although it is not present in the file system - maybe we should fix >>> that as well). >>> >>> If we are building on Windows, I convert the content of >>> 'sun.boot.class.path' to Unix form to avoid problems with the FIXPATH >>> utility. Later, during the build, FIXPATH will convert the path list >>> back to Windows form. >>> >>> I've tested the new Solution on Linux, Windows, Solaris and AIX and >>> couldn't find any problems. >>> >>> I would like to put this into the ppc-aix-port/stage repository but as >>> this is a general fix and if you'd like to, it would be also OK if >>> you'd push it right to the build repository. >>> >>> Thank you and best regards, >>> Volker >> >>
