Hi Magnus, is the msys build currently working (i.e. can I test it out of the box)? I think otherwise it would be hard to get this right for msys (it took me quite some time to get it right on Cygwin, so without a full sucessfull build I wouldn't bet on it:)
I agree that we shouldnt unnecessarily break the msys build. Actually, I contributed the first msys changes for jdk7:) I'll try to find a solution which works on both systems... Volker On Monday, November 18, 2013, Magnus Ihse Bursie wrote: > 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<javascript:;> > >: > > > > 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). > >>> >
