From kelly.ohair at oracle.com Fri Mar 1 09:18:14 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Mar 2013 09:18:14 -0800 Subject: New official README-builds.html Message-ID: Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. The very latest README-builds.html file is: http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html This documents the new build makefiles only. As with all documents of this type, it will always be a work in progress. -kto From d.lopez.j at gmail.com Mon Mar 4 03:18:06 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 12:18:06 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: This happens trying to test Java 8 following the instructions described in http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought were related to the new system and then trying to test the installation using the instructions provided here http://java.net/projects/adoptopenjdk/pages/InstallJtreg. Is this the old system of testing the jdk? The building itself succeeds, it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to be precise. Nevertheless, I'll try to build the make from the sources and see if that also fixes it. Thanks, D. 2013/3/4 Erik Joelsson > I'm assuming this is concerning jdk7 (and the old build system) so moving > to the build-dev list. This is a known issue in the cygwin version of make. > It can be addressed by building it yourself from source, enabling the > feature to accept ':' in paths. See the build readme for more details. > > http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** > README-builds.html#gmake > > (In the new build system in jdk8, this is solved differently and should > not be an issue.) > > /Erik > > > On 2013-02-27 13:05, Daniel L?pez wrote: > >> Hi there, >> I've been redirected here from the Adopt OpenJDK programme, as the >> investigation while trying to "adopt" the OpenJDK build using Windows has >> led me to some issues involving the build scripts. >> Back to the point, I was able to successfully build the OpenJDK following >> the instructions from the programme, but when it was time to verify the >> build, the make did not succeed. After some research, I found out that one >> of the issues is that, under Cygwin, the JDK does not like being passed >> the >> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >> is unable to work with the DOS adapted ones (due to the presence of ':' in >> the paths that is interpreted as path separators). The Makefile is >> transforming that paths and use them in several places (using cygpath -m >> -s >> ) but then it fails with a "multiple targets" error due to ':' being used >> in some paths. >> >> The solution I found was to convert the paths that are used internally >> inside the Makefile using 'cygpath -u' and use the DOS paths when they are >> passed to call the jtreg tool (a Java call). It surely needs some testing >> and MK might have a similar problem (I have not tested it, I don't have it >> installed) but just I wanted to let you know about the issue, in case >> someone else has the same troubles. >> >> How would you like to proceed with it? Google did not produce any bug >> report that covered that and I'm quite new to the Adop OpenJDK programme >> and the whole OpenJDK contribution (the documentation is not too clear as >> it assumes a bug is already created and the bugDatabase page is a WIP). >> >> Cheers! >> D. >> >> To follow the whole discussion, the topic at the Adopt OpenJDK google >> group >> should be here: >> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >> topic/adopt-openjdk/**qRdMlWFgrhc >> > From d.lopez.j at gmail.com Mon Mar 4 03:18:30 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 12:18:30 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: I just tried downloading and building myself make 3.80 (as Mozilla guys suggest) or the newest 3.82 and none of them is able to run the Makefile unmodified :(. S! D. 2013/3/4 Daniel L?pez > This happens trying to test Java 8 following the instructions described in > http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought > were related to the new system and then trying to test the installation > using the instructions provided here > http://java.net/projects/adoptopenjdk/pages/InstallJtreg. > > Is this the old system of testing the jdk? The building itself succeeds, > it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to > be precise. > Nevertheless, I'll try to build the make from the sources and see if that > also fixes it. > > Thanks, > D. > > > 2013/3/4 Erik Joelsson > >> I'm assuming this is concerning jdk7 (and the old build system) so moving >> to the build-dev list. This is a known issue in the cygwin version of make. >> It can be addressed by building it yourself from source, enabling the >> feature to accept ':' in paths. See the build readme for more details. >> >> http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** >> README-builds.html#gmake >> >> (In the new build system in jdk8, this is solved differently and should >> not be an issue.) >> >> /Erik >> >> >> On 2013-02-27 13:05, Daniel L?pez wrote: >> >>> Hi there, >>> I've been redirected here from the Adopt OpenJDK programme, as the >>> investigation while trying to "adopt" the OpenJDK build using Windows has >>> led me to some issues involving the build scripts. >>> Back to the point, I was able to successfully build the OpenJDK following >>> the instructions from the programme, but when it was time to verify the >>> build, the make did not succeed. After some research, I found out that >>> one >>> of the issues is that, under Cygwin, the JDK does not like being passed >>> the >>> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >>> is unable to work with the DOS adapted ones (due to the presence of ':' >>> in >>> the paths that is interpreted as path separators). The Makefile is >>> transforming that paths and use them in several places (using cygpath -m >>> -s >>> ) but then it fails with a "multiple targets" error due to ':' being used >>> in some paths. >>> >>> The solution I found was to convert the paths that are used internally >>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>> are >>> passed to call the jtreg tool (a Java call). It surely needs some testing >>> and MK might have a similar problem (I have not tested it, I don't have >>> it >>> installed) but just I wanted to let you know about the issue, in case >>> someone else has the same troubles. >>> >>> How would you like to proceed with it? Google did not produce any bug >>> report that covered that and I'm quite new to the Adop OpenJDK programme >>> and the whole OpenJDK contribution (the documentation is not too clear as >>> it assumes a bug is already created and the bugDatabase page is a WIP). >>> >>> Cheers! >>> D. >>> >>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>> group >>> should be here: >>> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >>> topic/adopt-openjdk/**qRdMlWFgrhc >>> >> > From erik.joelsson at oracle.com Mon Mar 4 03:52:20 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 12:52:20 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: <51348AF4.5060108@oracle.com> I see. Yes, this is the new build. The test targets haven't been addressed yet though so the problem with : probably persists there. You might need to build make with some special option to enable the : feature. I have never done this myself so I don't know the details. /Erik On 2013-03-04 12:18, Daniel L?pez wrote: > I just tried downloading and building myself make 3.80 (as Mozilla guys > suggest) or the newest 3.82 and none of them is able to run the Makefile > unmodified :(. > > S! > D. > > > 2013/3/4 Daniel L?pez > >> This happens trying to test Java 8 following the instructions described in >> http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought >> were related to the new system and then trying to test the installation >> using the instructions provided here >> http://java.net/projects/adoptopenjdk/pages/InstallJtreg. >> >> Is this the old system of testing the jdk? The building itself succeeds, >> it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to >> be precise. >> Nevertheless, I'll try to build the make from the sources and see if that >> also fixes it. >> >> Thanks, >> D. >> >> >> 2013/3/4 Erik Joelsson >> >>> I'm assuming this is concerning jdk7 (and the old build system) so moving >>> to the build-dev list. This is a known issue in the cygwin version of make. >>> It can be addressed by building it yourself from source, enabling the >>> feature to accept ':' in paths. See the build readme for more details. >>> >>> http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** >>> README-builds.html#gmake >>> >>> (In the new build system in jdk8, this is solved differently and should >>> not be an issue.) >>> >>> /Erik >>> >>> >>> On 2013-02-27 13:05, Daniel L?pez wrote: >>> >>>> Hi there, >>>> I've been redirected here from the Adopt OpenJDK programme, as the >>>> investigation while trying to "adopt" the OpenJDK build using Windows has >>>> led me to some issues involving the build scripts. >>>> Back to the point, I was able to successfully build the OpenJDK following >>>> the instructions from the programme, but when it was time to verify the >>>> build, the make did not succeed. After some research, I found out that >>>> one >>>> of the issues is that, under Cygwin, the JDK does not like being passed >>>> the >>>> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >>>> is unable to work with the DOS adapted ones (due to the presence of ':' >>>> in >>>> the paths that is interpreted as path separators). The Makefile is >>>> transforming that paths and use them in several places (using cygpath -m >>>> -s >>>> ) but then it fails with a "multiple targets" error due to ':' being used >>>> in some paths. >>>> >>>> The solution I found was to convert the paths that are used internally >>>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>>> are >>>> passed to call the jtreg tool (a Java call). It surely needs some testing >>>> and MK might have a similar problem (I have not tested it, I don't have >>>> it >>>> installed) but just I wanted to let you know about the issue, in case >>>> someone else has the same troubles. >>>> >>>> How would you like to proceed with it? Google did not produce any bug >>>> report that covered that and I'm quite new to the Adop OpenJDK programme >>>> and the whole OpenJDK contribution (the documentation is not too clear as >>>> it assumes a bug is already created and the bugDatabase page is a WIP). >>>> >>>> Cheers! >>>> D. >>>> >>>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>>> group >>>> should be here: >>>> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >>>> topic/adopt-openjdk/**qRdMlWFgrhc >>>> From d.lopez.j at gmail.com Mon Mar 4 04:39:25 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 13:39:25 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: <51348AF4.5060108@oracle.com> References: <513476BB.3040704@oracle.com> <51348AF4.5060108@oracle.com> Message-ID: Well, I have been able to modify the Makefile so it does not depend on make hanlding the ':', by transforming paths into linux style paths inside Make. Then the problem is that Java itself seems not to like the Cygwin paths (/cygdrive/c/...), maybe because it thinks it's running in windows?, so the paths passed to Java have to be properly formatted as well. So I have a working version of the Makefile, in Cygwin, and the question would be if we want to investigate further how to get make to work with that version or use the modified make-independent version. And in the latter case, I can provide I diff of my changes so they can be revised and tested. They are fairly simple changes but... :). S! D. 2013/3/4 Erik Joelsson > I see. Yes, this is the new build. The test targets haven't been addressed > yet though so the problem with : probably persists there. You might need to > build make with some special option to enable the : feature. I have never > done this myself so I don't know the details. > > /Erik > > > On 2013-03-04 12:18, Daniel L?pez wrote: > >> I just tried downloading and building myself make 3.80 (as Mozilla guys >> suggest) or the newest 3.82 and none of them is able to run the Makefile >> unmodified :(. >> >> S! >> D. >> >> >> 2013/3/4 Daniel L?pez >> >> This happens trying to test Java 8 following the instructions described >>> in >>> http://java.net/projects/**adoptopenjdk/pages/**BuildWindowsthat I thought >>> were related to the new system and then trying to test the installation >>> using the instructions provided here >>> http://java.net/projects/**adoptopenjdk/pages/**InstallJtreg >>> . >>> >>> Is this the old system of testing the jdk? The building itself succeeds, >>> it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) >>> to >>> be precise. >>> Nevertheless, I'll try to build the make from the sources and see if that >>> also fixes it. >>> >>> Thanks, >>> D. >>> >>> >>> 2013/3/4 Erik Joelsson >>> > >>> >>> I'm assuming this is concerning jdk7 (and the old build system) so >>>> moving >>>> to the build-dev list. This is a known issue in the cygwin version of >>>> make. >>>> It can be addressed by building it yourself from source, enabling the >>>> feature to accept ':' in paths. See the build readme for more details. >>>> >>>> http://hg.openjdk.java.net/****jdk7/build/raw-file/tip/** >>>> README-builds.html#gmake>>> build/raw-file/tip/README-**builds.html#gmake >>>> > >>>> >>>> >>>> (In the new build system in jdk8, this is solved differently and should >>>> not be an issue.) >>>> >>>> /Erik >>>> >>>> >>>> On 2013-02-27 13:05, Daniel L?pez wrote: >>>> >>>> Hi there, >>>>> I've been redirected here from the Adopt OpenJDK programme, as the >>>>> investigation while trying to "adopt" the OpenJDK build using Windows >>>>> has >>>>> led me to some issues involving the build scripts. >>>>> Back to the point, I was able to successfully build the OpenJDK >>>>> following >>>>> the instructions from the programme, but when it was time to verify the >>>>> build, the make did not succeed. After some research, I found out that >>>>> one >>>>> of the issues is that, under Cygwin, the JDK does not like being passed >>>>> the >>>>> Unix equivalent paths, so you need the DOS adapted ones, but the >>>>> Makefile >>>>> is unable to work with the DOS adapted ones (due to the presence of ':' >>>>> in >>>>> the paths that is interpreted as path separators). The Makefile is >>>>> transforming that paths and use them in several places (using cygpath >>>>> -m >>>>> -s >>>>> ) but then it fails with a "multiple targets" error due to ':' being >>>>> used >>>>> in some paths. >>>>> >>>>> The solution I found was to convert the paths that are used internally >>>>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>>>> are >>>>> passed to call the jtreg tool (a Java call). It surely needs some >>>>> testing >>>>> and MK might have a similar problem (I have not tested it, I don't have >>>>> it >>>>> installed) but just I wanted to let you know about the issue, in case >>>>> someone else has the same troubles. >>>>> >>>>> How would you like to proceed with it? Google did not produce any bug >>>>> report that covered that and I'm quite new to the Adop OpenJDK >>>>> programme >>>>> and the whole OpenJDK contribution (the documentation is not too clear >>>>> as >>>>> it assumes a bug is already created and the bugDatabase page is a WIP). >>>>> >>>>> Cheers! >>>>> D. >>>>> >>>>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>>>> group >>>>> should be here: >>>>> https://groups.google.com/****forum/?hl=es&fromgroups=#!** >>>>> topic/adopt-openjdk/****qRdMlWFgrhc>>>> google.com/forum/?hl=es&**fromgroups=#!topic/adopt-** >>>>> openjdk/qRdMlWFgrhc >>>>> > >>>>> >>>>> From erik.joelsson at oracle.com Mon Mar 4 04:52:35 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 13:52:35 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> <51348AF4.5060108@oracle.com> Message-ID: <51349913.10608@oracle.com> Contributions are of course always appreciated, but the model for solving this in the new build is different. We have a utility, fixpath.exe, created by configure, which we prepend to all the windows executables that make runs. It rewrites all arguments containing /cygdrive/ paths to driveletter-colon paths before running the windows executable. This way we don't need to worry about converting paths in make, we just use unix style all over. I haven't looked at the test targets yet, so I don't know the details of what goes wrong there. Getting to look at your patch would give a better idea of what the problems are. /Erik On 2013-03-04 13:39, Daniel L?pez wrote: > Well, I have been able to modify the Makefile so it does not depend on make > hanlding the ':', by transforming paths into linux style paths inside Make. > Then the problem is that Java itself seems not to like the Cygwin paths > (/cygdrive/c/...), maybe because it thinks it's running in windows?, so the > paths passed to Java have to be properly formatted as well. > > So I have a working version of the Makefile, in Cygwin, and the question > would be if we want to investigate further how to get make to work with > that version or use the modified make-independent version. And in the > latter case, I can provide I diff of my changes so they can be revised and > tested. They are fairly simple changes but... :). > > S! > D. > > > 2013/3/4 Erik Joelsson > >> I see. Yes, this is the new build. The test targets haven't been addressed >> yet though so the problem with : probably persists there. You might need to >> build make with some special option to enable the : feature. I have never >> done this myself so I don't know the details. >> >> /Erik >> >> >> On 2013-03-04 12:18, Daniel L?pez wrote: >> >>> I just tried downloading and building myself make 3.80 (as Mozilla guys >>> suggest) or the newest 3.82 and none of them is able to run the Makefile >>> unmodified :(. >>> >>> S! >>> D. >>> >>> >>> 2013/3/4 Daniel L?pez >>> >>> This happens trying to test Java 8 following the instructions described >>>> in >>>> http://java.net/projects/**adoptopenjdk/pages/**BuildWindowsthat I thought >>>> were related to the new system and then trying to test the installation >>>> using the instructions provided here >>>> http://java.net/projects/**adoptopenjdk/pages/**InstallJtreg >>>> . >>>> >>>> Is this the old system of testing the jdk? The building itself succeeds, >>>> it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) >>>> to >>>> be precise. >>>> Nevertheless, I'll try to build the make from the sources and see if that >>>> also fixes it. >>>> >>>> Thanks, >>>> D. >>>> >>>> >>>> 2013/3/4 Erik Joelsson >>>> I'm assuming this is concerning jdk7 (and the old build system) so >>>>> moving >>>>> to the build-dev list. This is a known issue in the cygwin version of >>>>> make. >>>>> It can be addressed by building it yourself from source, enabling the >>>>> feature to accept ':' in paths. See the build readme for more details. >>>>> >>>>> http://hg.openjdk.java.net/****jdk7/build/raw-file/tip/** >>>>> README-builds.html#gmake>>>> build/raw-file/tip/README-**builds.html#gmake >>>>> >>>>> (In the new build system in jdk8, this is solved differently and should >>>>> not be an issue.) >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2013-02-27 13:05, Daniel L?pez wrote: >>>>> >>>>> Hi there, >>>>>> I've been redirected here from the Adopt OpenJDK programme, as the >>>>>> investigation while trying to "adopt" the OpenJDK build using Windows >>>>>> has >>>>>> led me to some issues involving the build scripts. >>>>>> Back to the point, I was able to successfully build the OpenJDK >>>>>> following >>>>>> the instructions from the programme, but when it was time to verify the >>>>>> build, the make did not succeed. After some research, I found out that >>>>>> one >>>>>> of the issues is that, under Cygwin, the JDK does not like being passed >>>>>> the >>>>>> Unix equivalent paths, so you need the DOS adapted ones, but the >>>>>> Makefile >>>>>> is unable to work with the DOS adapted ones (due to the presence of ':' >>>>>> in >>>>>> the paths that is interpreted as path separators). The Makefile is >>>>>> transforming that paths and use them in several places (using cygpath >>>>>> -m >>>>>> -s >>>>>> ) but then it fails with a "multiple targets" error due to ':' being >>>>>> used >>>>>> in some paths. >>>>>> >>>>>> The solution I found was to convert the paths that are used internally >>>>>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>>>>> are >>>>>> passed to call the jtreg tool (a Java call). It surely needs some >>>>>> testing >>>>>> and MK might have a similar problem (I have not tested it, I don't have >>>>>> it >>>>>> installed) but just I wanted to let you know about the issue, in case >>>>>> someone else has the same troubles. >>>>>> >>>>>> How would you like to proceed with it? Google did not produce any bug >>>>>> report that covered that and I'm quite new to the Adop OpenJDK >>>>>> programme >>>>>> and the whole OpenJDK contribution (the documentation is not too clear >>>>>> as >>>>>> it assumes a bug is already created and the bugDatabase page is a WIP). >>>>>> >>>>>> Cheers! >>>>>> D. >>>>>> >>>>>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>>>>> group >>>>>> should be here: >>>>>> https://groups.google.com/****forum/?hl=es&fromgroups=#!** >>>>>> topic/adopt-openjdk/****qRdMlWFgrhc>>>>> google.com/forum/?hl=es&**fromgroups=#!topic/adopt-** >>>>>> openjdk/qRdMlWFgrhc >>>>>> From d.lopez.j at gmail.com Mon Mar 4 05:33:17 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 14:33:17 +0100 Subject: Fwd: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: <51349913.10608@oracle.com> References: <513476BB.3040704@oracle.com> <51348AF4.5060108@oracle.com> <51349913.10608@oracle.com> Message-ID: Cool, that's why I wanted to check first if something was already there to handle those cases. The issue seems to be twofold: 1) Some paths that end up using ':' are not handled on the vmsqe_tests target, so I processed them like the other paths are: ------------- @@ -771,7 +771,7 @@ RUNVMSQE_BIN = $(RUNVMSQE_HOME)/bin/runvmsqe -vmsqe_tests: prep $(VMSQE_HOME)/vm $(TONGA3_HOME) $(RUNVMSQE_BIN) $(PRODUCT_HOME) +vmsqe_tests: prep $(shell $(GETMIXEDPATH) "$(VMSQE_HOME)")/vm $(shell $(GETMIXEDPATH) "$(TONGA3_HOME)") $(RUNVMSQE_BIN) $(PRODUCT_HOME) $(RM) -r $(ABS_TEST_OUTPUT_DIR)/vmsqe ( $(CD) $(ABS_TEST_OUTPUT_DIR) && \ $(RUNVMSQE_BIN) \ ----------------- 2) The Java command does not understand the cygwin paths so they have to be changed for the windows equivalents when calling jtreg itself (GETMIXEDPATH_JAVA is the opposite routine of GETMIXEDPATH, from Linux like paths to Windows paths): ----------------- @@ -668,14 +668,14 @@ | $(CUT) -d' ' -f1 \ | $(SED) -e 's@^@Excluding: @' ( \ - ( JT_HOME=$(shell $(GETMIXEDPATH) "$(JT_HOME)"); \ + ( JT_HOME=$(shell $(GETMIXEDPATH_JAVA) "$(JT_HOME)"); \ export JT_HOME; \ - $(shell $(GETMIXEDPATH) "$(JTREG)") \ + $(shell $(GETMIXEDPATH_JAVA) "$(JTREG)") \ $(JTREG_BASIC_OPTIONS) \ - -r:$(shell $(GETMIXEDPATH) "$(ABS_TEST_OUTPUT_DIR)")/JTreport \ - -w:$(shell $(GETMIXEDPATH) "$(ABS_TEST_OUTPUT_DIR)")/JTwork \ - -jdk:$(shell $(GETMIXEDPATH) "$(PRODUCT_HOME)") \ - -exclude:$(shell $(GETMIXEDPATH) "$(EXCLUDELIST)") \ + -r:$(shell $(GETMIXEDPATH_JAVA) "$(ABS_TEST_OUTPUT_DIR)")/JTreport \ + -w:$(shell $(GETMIXEDPATH_JAVA) "$(ABS_TEST_OUTPUT_DIR)")/JTwork \ + -jdk:$(shell $(GETMIXEDPATH_JAVA) "$(PRODUCT_HOME)") \ + -exclude:$(shell $(GETMIXEDPATH_JAVA) "$(EXCLUDELIST)") \ $(JTREG_TEST_OPTIONS) \ $(TESTDIRS) \ ) ; $(BUNDLE_UP_AND_EXIT) ----------------- I hope it helps, D. 2013/3/4 Erik Joelsson > Contributions are of course always appreciated, but the model for solving > this in the new build is different. We have a utility, fixpath.exe, created > by configure, which we prepend to all the windows executables that make > runs. It rewrites all arguments containing /cygdrive/ paths to > driveletter-colon paths before running the windows executable. This way we > don't need to worry about converting paths in make, we just use unix style > all over. I haven't looked at the test targets yet, so I don't know the > details of what goes wrong there. Getting to look at your patch would give > a better idea of what the problems are. > > /Erik > > > On 2013-03-04 13:39, Daniel L?pez wrote: > >> Well, I have been able to modify the Makefile so it does not depend on >> make >> hanlding the ':', by transforming paths into linux style paths inside >> Make. >> Then the problem is that Java itself seems not to like the Cygwin paths >> (/cygdrive/c/...), maybe because it thinks it's running in windows?, so >> the >> paths passed to Java have to be properly formatted as well. >> >> So I have a working version of the Makefile, in Cygwin, and the question >> would be if we want to investigate further how to get make to work with >> that version or use the modified make-independent version. And in the >> latter case, I can provide I diff of my changes so they can be revised and >> tested. They are fairly simple changes but... :). >> >> S! >> D. >> >> >> 2013/3/4 Erik Joelsson >> > >> >> I see. Yes, this is the new build. The test targets haven't been >>> addressed >>> yet though so the problem with : probably persists there. You might need >>> to >>> build make with some special option to enable the : feature. I have never >>> done this myself so I don't know the details. >>> >>> /Erik >>> >>> >>> On 2013-03-04 12:18, Daniel L?pez wrote: >>> >>> I just tried downloading and building myself make 3.80 (as Mozilla guys >>>> suggest) or the newest 3.82 and none of them is able to run the Makefile >>>> unmodified :(. >>>> >>>> S! >>>> D. >>>> >>>> >>>> 2013/3/4 Daniel L?pez >>>> >>>> This happens trying to test Java 8 following the instructions >>>> described >>>> >>>>> in >>>>> http://java.net/projects/****adoptopenjdk/pages/****BuildWindows >>>>> >that >>>>> I thought >>>>> >>>>> were related to the new system and then trying to test the installation >>>>> using the instructions provided here >>>>> http://java.net/projects/****adoptopenjdk/pages/****InstallJtreg >>>>> >>>>> > >>>>> >>>>> . >>>>> >>>>> Is this the old system of testing the jdk? The building itself >>>>> succeeds, >>>>> it's the test Makefile that gives me troubles >>>>> (OpenJDK/jdk8_tl/jdk/test) >>>>> to >>>>> be precise. >>>>> Nevertheless, I'll try to build the make from the sources and see if >>>>> that >>>>> also fixes it. >>>>> >>>>> Thanks, >>>>> D. >>>>> >>>>> >>>>> 2013/3/4 Erik Joelsson>>>> erik.joelsson at oracle.com**> >>>>> >>>>> I'm assuming this is concerning jdk7 (and the old build system) so >>>>> >>>>>> moving >>>>>> to the build-dev list. This is a known issue in the cygwin version of >>>>>> make. >>>>>> It can be addressed by building it yourself from source, enabling the >>>>>> feature to accept ':' in paths. See the build readme for more details. >>>>>> >>>>>> http://hg.openjdk.java.net/******jdk7/build/raw-file/tip/** >>>>>> >>>>>> > >>>>>> README-builds.html#gmake >>>>>> build/raw-file/tip/README-****builds.html#gmake>>>>> openjdk.java.net/jdk7/build/**raw-file/tip/README-builds.**html#gmake >>>>>> > >>>>>> >>>>>> >>>>>> (In the new build system in jdk8, this is solved differently and >>>>>> should >>>>>> not be an issue.) >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2013-02-27 13:05, Daniel L?pez wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>>> I've been redirected here from the Adopt OpenJDK programme, as the >>>>>>> investigation while trying to "adopt" the OpenJDK build using Windows >>>>>>> has >>>>>>> led me to some issues involving the build scripts. >>>>>>> Back to the point, I was able to successfully build the OpenJDK >>>>>>> following >>>>>>> the instructions from the programme, but when it was time to verify >>>>>>> the >>>>>>> build, the make did not succeed. After some research, I found out >>>>>>> that >>>>>>> one >>>>>>> of the issues is that, under Cygwin, the JDK does not like being >>>>>>> passed >>>>>>> the >>>>>>> Unix equivalent paths, so you need the DOS adapted ones, but the >>>>>>> Makefile >>>>>>> is unable to work with the DOS adapted ones (due to the presence of >>>>>>> ':' >>>>>>> in >>>>>>> the paths that is interpreted as path separators). The Makefile is >>>>>>> transforming that paths and use them in several places (using cygpath >>>>>>> -m >>>>>>> -s >>>>>>> ) but then it fails with a "multiple targets" error due to ':' being >>>>>>> used >>>>>>> in some paths. >>>>>>> >>>>>>> The solution I found was to convert the paths that are used >>>>>>> internally >>>>>>> inside the Makefile using 'cygpath -u' and use the DOS paths when >>>>>>> they >>>>>>> are >>>>>>> passed to call the jtreg tool (a Java call). It surely needs some >>>>>>> testing >>>>>>> and MK might have a similar problem (I have not tested it, I don't >>>>>>> have >>>>>>> it >>>>>>> installed) but just I wanted to let you know about the issue, in case >>>>>>> someone else has the same troubles. >>>>>>> >>>>>>> How would you like to proceed with it? Google did not produce any bug >>>>>>> report that covered that and I'm quite new to the Adop OpenJDK >>>>>>> programme >>>>>>> and the whole OpenJDK contribution (the documentation is not too >>>>>>> clear >>>>>>> as >>>>>>> it assumes a bug is already created and the bugDatabase page is a >>>>>>> WIP). >>>>>>> >>>>>>> Cheers! >>>>>>> D. >>>>>>> >>>>>>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>>>>>> group >>>>>>> should be here: >>>>>>> https://groups.google.com/******forum/?hl=es&fromgroups=#!** >>>>>>> >>>>>>> > >>>>>>> topic/adopt-openjdk/******qRdMlWFgrhc>>>>>> google.com/forum/?hl=es&****fromgroups=#!topic/adopt-** >>>>>>> openjdk/qRdMlWFgrhc>>>>>> es&fromgroups=#!topic/adopt-**openjdk/qRdMlWFgrhc >>>>>>> > >>>>>>> >>>>>>> From erik.joelsson at oracle.com Mon Mar 4 07:30:11 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:11 +0000 Subject: hg: build-infra/jdk8/corba: 3 new changesets Message-ID: <20130304153017.C765747808@hg.openjdk.java.net> Changeset: e41fb1aa0329 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/e41fb1aa0329 Added tag jdk8-b78 for changeset 27d6368ae8ba ! .hgtags Changeset: 5f3d4a6bdd02 Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/5f3d4a6bdd02 Added tag jdk8-b79 for changeset e41fb1aa0329 ! .hgtags Changeset: a1b823e37a03 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/a1b823e37a03 Merge From erik.joelsson at oracle.com Mon Mar 4 07:30:16 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:16 +0000 Subject: hg: build-infra/jdk8/jaxws: 3 new changesets Message-ID: <20130304153034.5A14747809@hg.openjdk.java.net> Changeset: 70d8658d2a30 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/70d8658d2a30 Added tag jdk8-b78 for changeset 391de4c992d1 ! .hgtags Changeset: b0224010e2f0 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/b0224010e2f0 Added tag jdk8-b79 for changeset 70d8658d2a30 ! .hgtags Changeset: 05324426f3f8 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/05324426f3f8 Merge From erik.joelsson at oracle.com Mon Mar 4 07:30:16 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:16 +0000 Subject: hg: build-infra/jdk8/jaxp: 3 new changesets Message-ID: <20130304153038.D50584780A@hg.openjdk.java.net> Changeset: 58fa065dd5d6 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/58fa065dd5d6 Added tag jdk8-b78 for changeset 00958c5a7070 ! .hgtags Changeset: 4873a0499bc3 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/4873a0499bc3 Added tag jdk8-b79 for changeset 58fa065dd5d6 ! .hgtags Changeset: ba7b7f7a4425 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/ba7b7f7a4425 Merge From erik.joelsson at oracle.com Mon Mar 4 07:30:20 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:20 +0000 Subject: hg: build-infra/jdk8/langtools: 3 new changesets Message-ID: <20130304153041.B4E144780B@hg.openjdk.java.net> Changeset: 56dfafbb9e1a Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/56dfafbb9e1a Added tag jdk8-b78 for changeset af8417e590f4 ! .hgtags Changeset: a8227c617684 Author: katleman Date: 2013-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/a8227c617684 Added tag jdk8-b79 for changeset 56dfafbb9e1a ! .hgtags Changeset: b448b4405437 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/b448b4405437 Merge From erik.joelsson at oracle.com Mon Mar 4 07:30:15 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:15 +0000 Subject: hg: build-infra/jdk8/hotspot: 42 new changesets Message-ID: <20130304153202.9C65B4780C@hg.openjdk.java.net> Changeset: d7db5612a679 Author: erikj Date: 2013-02-20 15:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/d7db5612a679 Fixed comment. ! make/bsd/makefiles/gcc.make Changeset: db3359133cdd Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/db3359133cdd Added tag jdk8-b78 for changeset d5e12e7d2f71 ! .hgtags Changeset: 57b81d6c3641 Author: amurillo Date: 2013-02-15 13:36 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/57b81d6c3641 8008286: new hotspot build - hs25-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7adae9244bc8 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/7adae9244bc8 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp Changeset: 2394a89e89f4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/2394a89e89f4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c Changeset: 49618582fc5b Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/49618582fc5b 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 3a531d40ad93 Author: acorn Date: 2013-02-14 14:33 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/3a531d40ad93 8007736: VerifyError for static method in interface Reviewed-by: dholmes, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/verifier.cpp + test/runtime/8007736/TestStaticIF.java Changeset: e7e9e08147fc Author: mikael Date: 2013-02-14 12:36 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/e7e9e08147fc 8007639: Workaround for ccache in vm.make is incorrect Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o Reviewed-by: dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: 5d5c577296fd Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5d5c577296fd 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: f35f1fbab3e1 Author: sla Date: 2013-02-15 10:08 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/f35f1fbab3e1 Merge Changeset: dc1de5e78a85 Author: dsamersoff Date: 2013-02-15 10:29 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/dc1de5e78a85 Merge Changeset: f82bcc429e8c Author: sla Date: 2013-02-18 10:43 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/f82bcc429e8c 8007901: SA: Don't read flag values as constants Reviewed-by: dholmes, mikael ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b5e3ec9c69fa Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b5e3ec9c69fa 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp Changeset: 5cd2fac2ae70 Author: hseigel Date: 2013-02-19 08:51 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5cd2fac2ae70 6749267: Signal handler should save/restore errno Summary: Save errno before processing signal, then restore it. Reviewed-by: acorn, sspitsyn ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 56c364daccc3 Author: emc Date: 2013-02-19 11:36 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/56c364daccc3 8007153: Ensure that MethodParameters API works properly with RedefineClasses Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 1048edb5434a Author: coleenp Date: 2013-02-19 13:33 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/1048edb5434a Merge Changeset: 20fff74158eb Author: sspitsyn Date: 2013-02-20 08:51 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/20fff74158eb Merge Changeset: bbc7936779f9 Author: brutisso Date: 2013-02-14 09:11 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/bbc7936779f9 8006398: Add regression tests for deprectated GCs Reviewed-by: ehelin, jwilhelm, jmasa ! test/TEST.ROOT + test/gc/startup_warnings/TestCMS.java + test/gc/startup_warnings/TestCMSIncrementalMode.java + test/gc/startup_warnings/TestCMSNoIncrementalMode.java + test/gc/startup_warnings/TestDefNewCMS.java + test/gc/startup_warnings/TestG1.java + test/gc/startup_warnings/TestIncGC.java + test/gc/startup_warnings/TestParNewCMS.java + test/gc/startup_warnings/TestParNewSerialOld.java + test/gc/startup_warnings/TestParallelGC.java + test/gc/startup_warnings/TestParallelScavengeSerialOld.java + test/gc/startup_warnings/TestSerialGC.java Changeset: fd7b3770c77e Author: tamao Date: 2013-02-14 14:43 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/fd7b3770c77e 8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy. Reviewed-by: jmasa Contributed-by: Tao Mao ! src/share/vm/memory/collectorPolicy.cpp Changeset: ccc57295818b Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ccc57295818b 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: b9c5e46bf915 Author: johnc Date: 2013-02-20 12:52 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b9c5e46bf915 8008188: Add regression test for 8005875 Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd Thread.print" against itself. Without the fix for 8005875 the test will crash. Reviewed-by: brutisso + test/gc/TestG1ZeroPGCTJcmdThreadPrint.java Changeset: 5741d3fc502d Author: brutisso Date: 2013-02-21 13:13 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5741d3fc502d Merge Changeset: c59b7900a2bd Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/c59b7900a2bd 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 514efad5e81a Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/514efad5e81a 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: a2bc322ca273 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/a2bc322ca273 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: ad736b4683b4 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ad736b4683b4 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java Changeset: 2e4b16122164 Author: vlivanov Date: 2013-02-21 06:29 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/2e4b16122164 Merge Changeset: 579f6adb7f51 Author: jprovino Date: 2013-02-05 13:32 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/579f6adb7f51 8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer Summary: A warning message should be displayed if these options are used with the Minimal VM. Reviewed-by: dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp Changeset: 9e2da96f9976 Author: bpittore Date: 2013-02-08 16:08 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/9e2da96f9976 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6c2da81297c5 Author: kvn Date: 2013-02-12 09:54 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6c2da81297c5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 84a926fe53d0 Author: bpittore Date: 2013-01-24 13:27 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/84a926fe53d0 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: cf9a2071eeac Author: jprovino Date: 2013-02-14 11:07 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/cf9a2071eeac 8006878: Some non-existent GC source files are in the minimalVM exclude list. Summary: cmsPermGen.cpp, psPermGen.cpp have been removed. yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice. Reviewed-by: dholmes, jmasa ! make/excludeSrc.make ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 1605eef8e11e Author: jprovino Date: 2013-02-14 11:08 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/1605eef8e11e 8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm. Reviewed-by: dholmes, cjplummer ! src/share/vm/runtime/arguments.cpp Changeset: 9c7d0948523f Author: jprovino Date: 2013-02-15 14:42 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/9c7d0948523f Merge Changeset: 1ba18258caa4 Author: bpittore Date: 2013-02-15 21:53 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/1ba18258caa4 Merge ! src/share/vm/runtime/arguments.cpp Changeset: abf488c22e09 Author: bpittore Date: 2013-02-20 23:29 -0500 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/abf488c22e09 Merge Changeset: 2af22eb04623 Author: vladidan Date: 2013-02-21 09:08 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/2af22eb04623 Merge Changeset: ed96c6015470 Author: vladidan Date: 2013-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/ed96c6015470 Merge Changeset: 555ec35a2507 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/555ec35a2507 Merge Changeset: 6691814929b6 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/6691814929b6 Added tag hs25-b20 for changeset 555ec35a2507 ! .hgtags Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags Changeset: 051c4490f3a1 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/051c4490f3a1 Merge ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make From erik.joelsson at oracle.com Mon Mar 4 07:30:20 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 15:30:20 +0000 Subject: hg: build-infra/jdk8/jdk: 12 new changesets Message-ID: <20130304153326.303774780D@hg.openjdk.java.net> Changeset: 5a1ea5bbe10a Author: erikj Date: 2013-02-21 14:14 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5a1ea5bbe10a 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Reviewed-by: tbell ! makefiles/Images.gmk Changeset: a287f6a0d46d Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/a287f6a0d46d 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! make/common/Defs-macosx.gmk Changeset: 5d27f8702118 Author: erikj Date: 2013-02-21 14:23 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5d27f8702118 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Reviewed-by: tbell, ohair ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk Changeset: bb97c93e4fd7 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/bb97c93e4fd7 Added tag jdk8-b78 for changeset 00b7535d743f ! .hgtags Changeset: f0b5b57014b3 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f0b5b57014b3 Merge Changeset: 5245b2f1c53d Author: ngthomas Date: 2013-02-21 17:55 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/5245b2f1c53d 8008691: Build failure (NEWBUILD=false) on Mac Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: c933505d75c2 Author: dcherepanov Date: 2013-02-26 12:54 +0400 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/c933505d75c2 Merge Changeset: 8d3dbb724859 Author: katleman Date: 2013-02-27 13:10 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/8d3dbb724859 Merge Changeset: b760d5d4b8d3 Author: katleman Date: 2013-02-28 19:30 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/b760d5d4b8d3 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk Changeset: d967dd39a5ca Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/d967dd39a5ca Added tag jdk8-b79 for changeset c933505d75c2 ! .hgtags Changeset: dfb40f066c6c Author: katleman Date: 2013-02-28 20:30 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/dfb40f066c6c Merge Changeset: ffd766bfc102 Author: erikj Date: 2013-03-04 16:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/ffd766bfc102 Merge ! makefiles/Images.gmk From kelly.ohair at oracle.com Mon Mar 4 08:02:20 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Mar 2013 08:02:20 -0800 Subject: New official README-builds.html In-Reply-To: <5130FF85.1030100@oracle.com> References: <5130FF85.1030100@oracle.com> Message-ID: <4A279FD0-F3FA-4F87-932B-1E4BE955E3E9@oracle.com> Using any paths with blanks in them is a risk, I would use a boot jdk that has a path without spaces. I also never use the java installed by any automated process, or system update mechanism because your boot jdk could change on you at any time. I get the jdk image needed, e.g. 7u7 or whatever, put it in a simple short directory, and keep it safe. Predictable build results is a matter of minimizing the variability, so you really never want to use things that are constantly changing on you. Some things you cannot control, but some you can. I am not a MSYS user, but I have heard there were some stability issues, so step one might be to use --with-num-cores=1 to start, until you get it working. -kto On Mar 1, 2013, at 11:20 AM, Akhil Arora wrote: > Hi Kelly > > I can build without any problems on linux. I'm trying to follow the instructions in the new README to build on Windows 7 with MSYS, but my build gets stuck, the output on the console with LOG=debug is > > make[1]: Entering directory `/d/nashorn/langtools/makefiles' > /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources > /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources > > I checked, this dir has been created, but the build gets stuck at this step for a long time. The only process running (in Task Manager) at this time is make. The flags I used for configure are - > > $ bash ./configure --prefix=/d --disable-headful -with-freetype=/d/freetype-i586 --with-boot-jdk=/d/Program\ Files/Java/jdk1.7.0 --with-num-cores=2 --with-memory-size=2048 --with-boot-jdk-jvmargs=-Xmx2g > > Any ideas? > > On 3/1/2013 9:18 AM, Kelly O'Hair wrote: >> >> Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. >> >> The very latest README-builds.html file is: >> http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html >> >> This documents the new build makefiles only. >> As with all documents of this type, it will always be a work in progress. >> >> -kto >> > From erik.joelsson at oracle.com Mon Mar 4 08:29:23 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 16:29:23 +0000 Subject: hg: build-infra/jdk8/jdk: Reverting change to Defs-untils.gmk. Message-ID: <20130304162948.ACE4547811@hg.openjdk.java.net> Changeset: e798adfcb6e8 Author: erikj Date: 2013-03-04 17:29 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/e798adfcb6e8 Reverting change to Defs-untils.gmk. ! make/common/shared/Defs-utils.gmk From d.lopez.j at gmail.com Mon Mar 4 11:25:25 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 20:25:25 +0100 Subject: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: I just tried 3.80 to see if I would get a different result from 3.82, which was not the case. The instructions in those pages were written by the guys at the Adopt OpenJDK programme, who redirected me to these lists.. And yes, I have followed the official instructions. Anyway, my apologies for bothering you. D. 2013/3/4 Kelly O'Hair > GNU make 3.81 NOT 3.80, but 3.82 should work too. > > And I have no idea who wrote up the instructions at: > http://java.net/projects/adoptopenjdk/pages/BuildWindows > http://java.net/projects/adoptopenjdk/pages/InstallJtreg. > > The instructions we support are at: > http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html > and if there are mistakes in that page, issues can be filed, and anyone is > welcome to fix it. > > -kto > > On Mar 4, 2013, at 3:15 AM, Daniel L?pez wrote: > > > I just tried downloading and building myself make 3.80 (as Mozilla guys > > suggest) or the newest 3.82 and none of them is able to run the Makefile > > unmodified :(. > > > > S! > > D. > > > > 2013/3/4 Daniel L?pez > > > >> This happens trying to test Java 8 following the instructions described > in > >> http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought > >> were related to the new system and then trying to test the installation > >> using the instructions provided here > >> http://java.net/projects/adoptopenjdk/pages/InstallJtreg. > >> > >> Is this the old system of testing the jdk? The building itself succeeds, > >> it's the test Makefile that gives me troubles > (OpenJDK/jdk8_tl/jdk/test) to > >> be precise. > >> Nevertheless, I'll try to build the make from the sources and see if > that > >> also fixes it. > >> > >> Thanks, > >> D. > >> > >> > >> 2013/3/4 Erik Joelsson > >> > >>> I'm assuming this is concerning jdk7 (and the old build system) so > moving > >>> to the build-dev list. This is a known issue in the cygwin version of > make. > >>> It can be addressed by building it yourself from source, enabling the > >>> feature to accept ':' in paths. See the build readme for more details. > >>> > >>> http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** > >>> README-builds.html#gmake< > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#gmake > > > >>> > >>> (In the new build system in jdk8, this is solved differently and should > >>> not be an issue.) > >>> > >>> /Erik > >>> > >>> > >>> On 2013-02-27 13:05, Daniel L?pez wrote: > >>> > >>>> Hi there, > >>>> I've been redirected here from the Adopt OpenJDK programme, as the > >>>> investigation while trying to "adopt" the OpenJDK build using Windows > has > >>>> led me to some issues involving the build scripts. > >>>> Back to the point, I was able to successfully build the OpenJDK > following > >>>> the instructions from the programme, but when it was time to verify > the > >>>> build, the make did not succeed. After some research, I found out that > >>>> one > >>>> of the issues is that, under Cygwin, the JDK does not like being > passed > >>>> the > >>>> Unix equivalent paths, so you need the DOS adapted ones, but the > Makefile > >>>> is unable to work with the DOS adapted ones (due to the presence of > ':' > >>>> in > >>>> the paths that is interpreted as path separators). The Makefile is > >>>> transforming that paths and use them in several places (using cygpath > -m > >>>> -s > >>>> ) but then it fails with a "multiple targets" error due to ':' being > used > >>>> in some paths. > >>>> > >>>> The solution I found was to convert the paths that are used internally > >>>> inside the Makefile using 'cygpath -u' and use the DOS paths when they > >>>> are > >>>> passed to call the jtreg tool (a Java call). It surely needs some > testing > >>>> and MK might have a similar problem (I have not tested it, I don't > have > >>>> it > >>>> installed) but just I wanted to let you know about the issue, in case > >>>> someone else has the same troubles. > >>>> > >>>> How would you like to proceed with it? Google did not produce any bug > >>>> report that covered that and I'm quite new to the Adop OpenJDK > programme > >>>> and the whole OpenJDK contribution (the documentation is not too > clear as > >>>> it assumes a bug is already created and the bugDatabase page is a > WIP). > >>>> > >>>> Cheers! > >>>> D. > >>>> > >>>> To follow the whole discussion, the topic at the Adopt OpenJDK google > >>>> group > >>>> should be here: > >>>> https://groups.google.com/**forum/?hl=es&fromgroups=#!** > >>>> topic/adopt-openjdk/**qRdMlWFgrhc< > https://groups.google.com/forum/?hl=es&fromgroups=#!topic/adopt-openjdk/qRdMlWFgrhc > > > >>>> > >>> > >> > > From kelly.ohair at oracle.com Mon Mar 4 17:57:12 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Mar 2013 17:57:12 -0800 Subject: New official README-builds.html In-Reply-To: <51350235.8010900@oracle.com> References: <5130FF85.1030100@oracle.com> <4A279FD0-F3FA-4F87-932B-1E4BE955E3E9@oracle.com> <51350235.8010900@oracle.com> Message-ID: <1604F323-2BE7-4250-AC59-9903986DBCBE@oracle.com> freetype 2.3 or newer is what the docs say, but I have heard that 2.4 might not work. I think we use 2.3.4 inside Oracle. -kto On Mar 4, 2013, at 12:21 PM, Akhil Arora wrote: > Thanks - I put the boot jdk in /d/jdk7 and added --with-num-cores=1, which made the hang go away and the build went further. > > Now I'm getting unresolved symbol errors for freetype when trying to build fontmanager.lib, I downloaded freetype from http://www.gtk.org/download/win32.php and used --with-freetype=/d/freetype-2.4.2-1 in configure - > > ## Starting jdk > Creating library d:/nashorn/build/windows-x86_64-normal-server-release/jdk/objs/libfontmanager/fontmanager.lib and object d:/nashorn/ > build/windows-x86_64-normal-server-release/jdk/objs/libfontmanager/fontmanager.exp > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Done_FreeType referenced in function freeNativeResources > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Done_Face referenced in function freeNativeResources > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Open_Face referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_New_Memory_Face referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Init_FreeType referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Activate_Size referenced in function setupFTContext > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Set_Char_Size referenced in function setupFTContext > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Set_Transform referenced in function setupFTContext > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_MulFix referenced in function Java_sun_font_FreetypeFontScaler_getFontMetricsNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Render_Glyph referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_GlyphSlot_Oblique referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_GlyphSlot_Embolden referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Load_Glyph referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Get_Char_Index referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Outline_Translate referenced in function getFTOutline > freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Outline_Get_BBox referenced in function Java_sun_font_FreetypeFontScaler_getGlyphOutlineBoundsNative > d:/nashorn/build/windows-x86_64-normal-server-release/jdk/bin/fontmanager.dll : fatal error LNK1120: 16 unresolved externals > make[2]: *** [/d/nashorn/build/windows-x86_64-normal-server-release/jdk/bin/fontmanager.dll] Error 96 > make[1]: *** [libs-only] Error 2 > make: *** [jdk-only] Error 2 > > On 3/4/2013 8:02 AM, Kelly O'Hair wrote: >> Using any paths with blanks in them is a risk, I would use a boot jdk that has a path without spaces. >> >> I also never use the java installed by any automated process, or system update mechanism because >> your boot jdk could change on you at any time. >> I get the jdk image needed, e.g. 7u7 or whatever, put it in a simple short directory, and keep it safe. >> >> Predictable build results is a matter of minimizing the variability, so you really never want to use >> things that are constantly changing on you. Some things you cannot control, but some you can. >> >> I am not a MSYS user, but I have heard there were some stability issues, so step one might be to use >> --with-num-cores=1 to start, until you get it working. >> >> -kto >> >> On Mar 1, 2013, at 11:20 AM, Akhil Arora wrote: >> >>> Hi Kelly >>> >>> I can build without any problems on linux. I'm trying to follow the instructions in the new README to build on Windows 7 with MSYS, but my build gets stuck, the output on the console with LOG=debug is >>> >>> make[1]: Entering directory `/d/nashorn/langtools/makefiles' >>> /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources >>> /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources >>> >>> I checked, this dir has been created, but the build gets stuck at this step for a long time. The only process running (in Task Manager) at this time is make. The flags I used for configure are - >>> >>> $ bash ./configure --prefix=/d --disable-headful -with-freetype=/d/freetype-i586 --with-boot-jdk=/d/Program\ Files/Java/jdk1.7.0 --with-num-cores=2 --with-memory-size=2048 --with-boot-jdk-jvmargs=-Xmx2g >>> >>> Any ideas? >>> >>> On 3/1/2013 9:18 AM, Kelly O'Hair wrote: >>>> >>>> Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. >>>> >>>> The very latest README-builds.html file is: >>>> http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html >>>> >>>> This documents the new build makefiles only. >>>> As with all documents of this type, it will always be a work in progress. >>>> >>>> -kto >>>> >>> >> > From philip.race at oracle.com Mon Mar 4 20:09:12 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 04 Mar 2013 20:09:12 -0800 Subject: New official README-builds.html In-Reply-To: <1604F323-2BE7-4250-AC59-9903986DBCBE@oracle.com> References: <5130FF85.1030100@oracle.com> <4A279FD0-F3FA-4F87-932B-1E4BE955E3E9@oracle.com> <51350235.8010900@oracle.com> <1604F323-2BE7-4250-AC59-9903986DBCBE@oracle.com> Message-ID: <51356FE8.5030107@oracle.com> There was at least one specific bad version of freetype that worked apparently to Linux users but not to people on an O/S with fonts with embedded bitmaps. But just like you aren't setting up your envt right such that it can't find the .so. If the build can't infer the lib location from the include location you will need to supply both, -phil. On 3/4/13 5:57 PM, Kelly O'Hair wrote: > freetype 2.3 or newer is what the docs say, but I have heard that 2.4 might not work. > I think we use 2.3.4 inside Oracle. > > -kto > > On Mar 4, 2013, at 12:21 PM, Akhil Arora wrote: > >> Thanks - I put the boot jdk in /d/jdk7 and added --with-num-cores=1, which made the hang go away and the build went further. >> >> Now I'm getting unresolved symbol errors for freetype when trying to build fontmanager.lib, I downloaded freetype from http://www.gtk.org/download/win32.php and used --with-freetype=/d/freetype-2.4.2-1 in configure - >> >> ## Starting jdk >> Creating library d:/nashorn/build/windows-x86_64-normal-server-release/jdk/objs/libfontmanager/fontmanager.lib and object d:/nashorn/ >> build/windows-x86_64-normal-server-release/jdk/objs/libfontmanager/fontmanager.exp >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Done_FreeType referenced in function freeNativeResources >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Done_Face referenced in function freeNativeResources >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Open_Face referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_New_Memory_Face referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Init_FreeType referenced in function Java_sun_font_FreetypeFontScaler_initNativeScaler >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Activate_Size referenced in function setupFTContext >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Set_Char_Size referenced in function setupFTContext >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Set_Transform referenced in function setupFTContext >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_MulFix referenced in function Java_sun_font_FreetypeFontScaler_getFontMetricsNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Render_Glyph referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_GlyphSlot_Oblique referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_GlyphSlot_Embolden referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Load_Glyph referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Get_Char_Index referenced in function Java_sun_font_FreetypeFontScaler_getGlyphImageNative >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Outline_Translate referenced in function getFTOutline >> freetypeScaler.obj : error LNK2019: unresolved external symbol FT_Outline_Get_BBox referenced in function Java_sun_font_FreetypeFontScaler_getGlyphOutlineBoundsNative >> d:/nashorn/build/windows-x86_64-normal-server-release/jdk/bin/fontmanager.dll : fatal error LNK1120: 16 unresolved externals >> make[2]: *** [/d/nashorn/build/windows-x86_64-normal-server-release/jdk/bin/fontmanager.dll] Error 96 >> make[1]: *** [libs-only] Error 2 >> make: *** [jdk-only] Error 2 >> >> On 3/4/2013 8:02 AM, Kelly O'Hair wrote: >>> Using any paths with blanks in them is a risk, I would use a boot jdk that has a path without spaces. >>> >>> I also never use the java installed by any automated process, or system update mechanism because >>> your boot jdk could change on you at any time. >>> I get the jdk image needed, e.g. 7u7 or whatever, put it in a simple short directory, and keep it safe. >>> >>> Predictable build results is a matter of minimizing the variability, so you really never want to use >>> things that are constantly changing on you. Some things you cannot control, but some you can. >>> >>> I am not a MSYS user, but I have heard there were some stability issues, so step one might be to use >>> --with-num-cores=1 to start, until you get it working. >>> >>> -kto >>> >>> On Mar 1, 2013, at 11:20 AM, Akhil Arora wrote: >>> >>>> Hi Kelly >>>> >>>> I can build without any problems on linux. I'm trying to follow the instructions in the new README to build on Windows 7 with MSYS, but my build gets stuck, the output on the console with LOG=debug is >>>> >>>> make[1]: Entering directory `/d/nashorn/langtools/makefiles' >>>> /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources >>>> /bin/mkdir -p /d/nashorn/build/windows-x86_64-normal-server-release/langtools/btclasses/bootstrap/com/sun/tools/doclets/internal/toolkit/resources >>>> >>>> I checked, this dir has been created, but the build gets stuck at this step for a long time. The only process running (in Task Manager) at this time is make. The flags I used for configure are - >>>> >>>> $ bash ./configure --prefix=/d --disable-headful -with-freetype=/d/freetype-i586 --with-boot-jdk=/d/Program\ Files/Java/jdk1.7.0 --with-num-cores=2 --with-memory-size=2048 --with-boot-jdk-jvmargs=-Xmx2g >>>> >>>> Any ideas? >>>> >>>> On 3/1/2013 9:18 AM, Kelly O'Hair wrote: >>>>> Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. >>>>> >>>>> The very latest README-builds.html file is: >>>>> http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html >>>>> >>>>> This documents the new build makefiles only. >>>>> As with all documents of this type, it will always be a work in progress. >>>>> >>>>> -kto >>>>> From erik.joelsson at oracle.com Wed Mar 6 02:41:02 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 06 Mar 2013 10:41:02 +0000 Subject: hg: build-infra/jdk8: 13 new changesets Message-ID: <20130306104103.B7A5F47890@hg.openjdk.java.net> Changeset: a5d6e9bd2611 Author: erikj Date: 2013-02-21 16:15 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/a5d6e9bd2611 Made bootcycle-images work with sjavac. Still fails in jdk. ! common/autoconf/bootcycle-spec.gmk.in ! common/makefiles/Main.gmk Changeset: ab82853d3365 Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/ab82853d3365 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: d3e3d5b06f45 Author: ohair Date: 2013-02-23 10:47 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/d3e3d5b06f45 8004712: build-infra: Move user guide from web pages to repository Summary: Just the initial work, will need more changes. Reviewed-by: tbell ! README ! README-builds.html Changeset: 91d35211e744 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/91d35211e744 Added tag jdk8-b78 for changeset fd1a5574cf68 ! .hgtags Changeset: 2778e6576e21 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/2778e6576e21 Merge Changeset: 85b5b4cc388c Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/85b5b4cc388c Added tag jdk8-b79 for changeset 91d35211e744 ! .hgtags Changeset: 0adf9c626bb1 Author: katleman Date: 2013-02-28 20:29 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/0adf9c626bb1 Merge Changeset: 7122991e4944 Author: erikj Date: 2013-03-05 14:01 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/7122991e4944 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 98e3900da4e2 Author: erikj Date: 2013-03-05 14:15 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/98e3900da4e2 Merge ! README ! README-builds.html ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 863ba29b17ed Author: erikj Date: 2013-03-05 14:17 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/863ba29b17ed Merge ! README-builds.html ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 907a926d3c96 Author: erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk Changeset: 52741ab7c601 Author: erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 985980b6a1e6 Author: erikj Date: 2013-03-06 11:40 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/985980b6a1e6 Merge ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk From erik.joelsson at oracle.com Wed Mar 6 02:41:04 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 06 Mar 2013 10:41:04 +0000 Subject: hg: build-infra/jdk8/jdk: 4 new changesets Message-ID: <20130306104238.450BA47891@hg.openjdk.java.net> Changeset: f8008fcfeb7c Author: erikj Date: 2013-03-05 14:02 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/f8008fcfeb7c 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? ! makefiles/CompileNativeLibraries.gmk Changeset: 7d072e033706 Author: erikj Date: 2013-03-06 10:46 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/7d072e033706 8009393: Supply correct AR to install build from InstallWrapper.gmk Reviewed-by: dholmes ! make/common/shared/Defs-utils.gmk Changeset: 86e28669728e Author: erikj Date: 2013-03-06 10:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/86e28669728e 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk Changeset: 0cc742a4f9a7 Author: erikj Date: 2013-03-06 11:40 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/0cc742a4f9a7 Merge ! make/common/shared/Defs-utils.gmk ! makefiles/CompileNativeLibraries.gmk From paul.sandoz at oracle.com Mon Mar 11 06:28:44 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 11 Mar 2013 14:28:44 +0100 Subject: Build broken on Mac In-Reply-To: References: Message-ID: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> Hi Ben, Cross posting to build-infra. On Mar 11, 2013, at 2:03 PM, Ben Evans wrote: > Hi, > > Latest head appears to be broken on Mac 10.7 - I get this crash with > both Oracle JDK 7u11& my last successful OpenJDK 8 as boot JDKs: > > Any ideas / what information would be helpful in diagnosing the cause > of the build crash? > I can build OK, but i am using 10.8.2. Paul. > Thanks, > > Ben > > ## Starting jdk > Importing CORBA classes.jar > Importing CORBA src.zip > Importing CORBA bin.zip > Importing JAXP classes.jar > Importing JAXP src.zip > Importing JAXWS classes.jar > Importing JAXWS src.zip > Importing LANGTOOLS src.zip > Importing LANGTOOLS classes.jar > Compiling 182 files for BUILD_TOOLS > Generating charsetmapping classes > no main manifest attribute, in > /Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar > Generating buffer classes > Generating exceptions classes > make[2]: *** [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/btclasses/_the.batch] > Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [gensrc-only] Error 2 > make: *** [jdk-only] Error 2 > From erik.joelsson at oracle.com Mon Mar 11 06:39:16 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 14:39:16 +0100 Subject: Build broken on Mac In-Reply-To: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> References: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> Message-ID: <513DDE84.3070200@oracle.com> This looks like either repositories out of sync (did you update all of them?) or needing to rerun configure. The way the command line for javac is constructed has changed, requiring synchronized changes between jdk and langtools repositories. /Erik On 2013-03-11 14:28, Paul Sandoz wrote: > Hi Ben, > > Cross posting to build-infra. > > On Mar 11, 2013, at 2:03 PM, Ben Evans wrote: > >> Hi, >> >> Latest head appears to be broken on Mac 10.7 - I get this crash with >> both Oracle JDK 7u11& my last successful OpenJDK 8 as boot JDKs: >> >> Any ideas / what information would be helpful in diagnosing the cause >> of the build crash? >> > I can build OK, but i am using 10.8.2. > > Paul. > > >> Thanks, >> >> Ben >> >> ## Starting jdk >> Importing CORBA classes.jar >> Importing CORBA src.zip >> Importing CORBA bin.zip >> Importing JAXP classes.jar >> Importing JAXP src.zip >> Importing JAXWS classes.jar >> Importing JAXWS src.zip >> Importing LANGTOOLS src.zip >> Importing LANGTOOLS classes.jar >> Compiling 182 files for BUILD_TOOLS >> Generating charsetmapping classes >> no main manifest attribute, in >> /Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar >> Generating buffer classes >> Generating exceptions classes >> make[2]: *** [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/btclasses/_the.batch] >> Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make[1]: *** [gensrc-only] Error 2 >> make: *** [jdk-only] Error 2 >> From benjamin.john.evans at gmail.com Mon Mar 11 06:49:30 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 11 Mar 2013 13:49:30 +0000 Subject: Build broken on Mac In-Reply-To: <513DDE84.3070200@oracle.com> References: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> <513DDE84.3070200@oracle.com> Message-ID: Thanks Erik. I updated, & reran configure & make clean before each run. Same result. I'll try re-cloning from fresh & trying again - will let you know how I get on. Thanks, Ben On Mon, Mar 11, 2013 at 1:39 PM, Erik Joelsson wrote: > This looks like either repositories out of sync (did you update all of > them?) or needing to rerun configure. The way the command line for javac is > constructed has changed, requiring synchronized changes between jdk and > langtools repositories. > > /Erik > > > On 2013-03-11 14:28, Paul Sandoz wrote: >> >> Hi Ben, >> >> Cross posting to build-infra. >> >> On Mar 11, 2013, at 2:03 PM, Ben Evans >> wrote: >> >>> Hi, >>> >>> Latest head appears to be broken on Mac 10.7 - I get this crash with >>> both Oracle JDK 7u11& my last successful OpenJDK 8 as boot JDKs: >>> >>> Any ideas / what information would be helpful in diagnosing the cause >>> of the build crash? >>> >> I can build OK, but i am using 10.8.2. >> >> Paul. >> >> >>> Thanks, >>> >>> Ben >>> >>> ## Starting jdk >>> Importing CORBA classes.jar >>> Importing CORBA src.zip >>> Importing CORBA bin.zip >>> Importing JAXP classes.jar >>> Importing JAXP src.zip >>> Importing JAXWS classes.jar >>> Importing JAXWS src.zip >>> Importing LANGTOOLS src.zip >>> Importing LANGTOOLS classes.jar >>> Compiling 182 files for BUILD_TOOLS >>> Generating charsetmapping classes >>> no main manifest attribute, in >>> >>> /Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar >>> Generating buffer classes >>> Generating exceptions classes >>> make[2]: *** >>> [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/btclasses/_the.batch] >>> Error 1 >>> make[2]: *** Waiting for unfinished jobs.... >>> make[1]: *** [gensrc-only] Error 2 >>> make: *** [jdk-only] Error 2 >>> > From benjamin.john.evans at gmail.com Mon Mar 11 08:16:18 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 11 Mar 2013 15:16:18 +0000 Subject: Build broken on Mac In-Reply-To: References: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> <513DDE84.3070200@oracle.com> Message-ID: Recloning appears to have solved this issue - but still no idea what caused it to break in the first place. Thanks, Ben On Mon, Mar 11, 2013 at 1:49 PM, Ben Evans wrote: > Thanks Erik. > > I updated, & reran configure & make clean before each run. Same result. > > I'll try re-cloning from fresh & trying again - will let you know how I get on. > > Thanks, > > Ben > > On Mon, Mar 11, 2013 at 1:39 PM, Erik Joelsson wrote: >> This looks like either repositories out of sync (did you update all of >> them?) or needing to rerun configure. The way the command line for javac is >> constructed has changed, requiring synchronized changes between jdk and >> langtools repositories. >> >> /Erik >> >> >> On 2013-03-11 14:28, Paul Sandoz wrote: >>> >>> Hi Ben, >>> >>> Cross posting to build-infra. >>> >>> On Mar 11, 2013, at 2:03 PM, Ben Evans >>> wrote: >>> >>>> Hi, >>>> >>>> Latest head appears to be broken on Mac 10.7 - I get this crash with >>>> both Oracle JDK 7u11& my last successful OpenJDK 8 as boot JDKs: >>>> >>>> Any ideas / what information would be helpful in diagnosing the cause >>>> of the build crash? >>>> >>> I can build OK, but i am using 10.8.2. >>> >>> Paul. >>> >>> >>>> Thanks, >>>> >>>> Ben >>>> >>>> ## Starting jdk >>>> Importing CORBA classes.jar >>>> Importing CORBA src.zip >>>> Importing CORBA bin.zip >>>> Importing JAXP classes.jar >>>> Importing JAXP src.zip >>>> Importing JAXWS classes.jar >>>> Importing JAXWS src.zip >>>> Importing LANGTOOLS src.zip >>>> Importing LANGTOOLS classes.jar >>>> Compiling 182 files for BUILD_TOOLS >>>> Generating charsetmapping classes >>>> no main manifest attribute, in >>>> >>>> /Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar >>>> Generating buffer classes >>>> Generating exceptions classes >>>> make[2]: *** >>>> [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/btclasses/_the.batch] >>>> Error 1 >>>> make[2]: *** Waiting for unfinished jobs.... >>>> make[1]: *** [gensrc-only] Error 2 >>>> make: *** [jdk-only] Error 2 >>>> >> From erik.joelsson at oracle.com Mon Mar 11 08:22:22 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 16:22:22 +0100 Subject: Build broken on Mac In-Reply-To: References: <39942A45-E309-4DD5-8165-B04339BAA621@oracle.com> <513DDE84.3070200@oracle.com> Message-ID: <513DF6AE.7000106@oracle.com> Verify that you are on the tip in every repo. Maybe there is an outstanding merge or something preventing hg from updating one of them. The important ones in this case would be langtools, root and jdk. /Erik On 2013-03-11 16:16, Ben Evans wrote: > Recloning appears to have solved this issue - but still no idea what > caused it to break in the first place. > > Thanks, > > Ben > > On Mon, Mar 11, 2013 at 1:49 PM, Ben Evans > wrote: >> Thanks Erik. >> >> I updated,& reran configure& make clean before each run. Same result. >> >> I'll try re-cloning from fresh& trying again - will let you know how I get on. >> >> Thanks, >> >> Ben >> >> On Mon, Mar 11, 2013 at 1:39 PM, Erik Joelsson wrote: >>> This looks like either repositories out of sync (did you update all of >>> them?) or needing to rerun configure. The way the command line for javac is >>> constructed has changed, requiring synchronized changes between jdk and >>> langtools repositories. >>> >>> /Erik >>> >>> >>> On 2013-03-11 14:28, Paul Sandoz wrote: >>>> Hi Ben, >>>> >>>> Cross posting to build-infra. >>>> >>>> On Mar 11, 2013, at 2:03 PM, Ben Evans >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Latest head appears to be broken on Mac 10.7 - I get this crash with >>>>> both Oracle JDK 7u11& my last successful OpenJDK 8 as boot JDKs: >>>>> >>>>> Any ideas / what information would be helpful in diagnosing the cause >>>>> of the build crash? >>>>> >>>> I can build OK, but i am using 10.8.2. >>>> >>>> Paul. >>>> >>>> >>>>> Thanks, >>>>> >>>>> Ben >>>>> >>>>> ## Starting jdk >>>>> Importing CORBA classes.jar >>>>> Importing CORBA src.zip >>>>> Importing CORBA bin.zip >>>>> Importing JAXP classes.jar >>>>> Importing JAXP src.zip >>>>> Importing JAXWS classes.jar >>>>> Importing JAXWS src.zip >>>>> Importing LANGTOOLS src.zip >>>>> Importing LANGTOOLS classes.jar >>>>> Compiling 182 files for BUILD_TOOLS >>>>> Generating charsetmapping classes >>>>> no main manifest attribute, in >>>>> >>>>> /Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar >>>>> Generating buffer classes >>>>> Generating exceptions classes >>>>> make[2]: *** >>>>> [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/btclasses/_the.batch] >>>>> Error 1 >>>>> make[2]: *** Waiting for unfinished jobs.... >>>>> make[1]: *** [gensrc-only] Error 2 >>>>> make: *** [jdk-only] Error 2 >>>>> From gnu.andrew at redhat.com Wed Mar 13 05:18:27 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 08:18:27 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <1487841229.17867859.1363176720175.JavaMail.root@redhat.com> Message-ID: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) and so thought I start out with a simple fix. http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ At the moment, if disable-zip-debug-info is not specified, the configure output is: checking if we should zip debug-info files... with no result as $enable_zip_debug_info is unset. This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will print the default ('yes') when the option is unspecified: checking if we should zip debug-info files... yes What actually took longer than the fix was updating the generated files. We seem to have already settled on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes as the system install is 2.69. I was able to get it down to something closer to what is expected by installing a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated files for this reason. So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Mar 13 05:58:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 22:58:55 +1000 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> References: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> Message-ID: <5140780F.3050503@oracle.com> Andrew, FWIW we are not tied to autoconf 2.67. There have already been a number of pushes using 2.68 and now 2.69 is also showing up. David On 13/03/2013 10:18 PM, Andrew Hughes wrote: > I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) > and so thought I start out with a simple fix. > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > At the moment, if disable-zip-debug-info is not specified, the configure output is: > > checking if we should zip debug-info files... > > with no result as $enable_zip_debug_info is unset. > > This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will > print the default ('yes') when the option is unspecified: > > checking if we should zip debug-info files... yes > > What actually took longer than the fix was updating the generated files. We seem to have already settled > on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes > as the system install is 2.69. I was able to get it down to something closer to what is expected by installing > a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated > files for this reason. > > So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference > to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. > > If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. > > Thanks, > From erik.joelsson at oracle.com Wed Mar 13 06:37:32 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Mar 2013 14:37:32 +0100 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> References: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> Message-ID: <5140811C.4060703@oracle.com> Hello, I created a bug for you: 8009988: build-infra: Fix configure output for zip debuginfo check As David says, we haven't decided on 2.67, but I would guess that a majority of the commits have been with that version. This change is a first step towards enforcing a specific version and I'm ok with that. The actual fix looks good to. You will still need a JDK reviewer to ok it. Also, please notify me when you push this so that the closed version of the configure script may also be regenerated. /Erik On 2013-03-13 13:18, Andrew Hughes wrote: > I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) > and so thought I start out with a simple fix. > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > At the moment, if disable-zip-debug-info is not specified, the configure output is: > > checking if we should zip debug-info files... > > with no result as $enable_zip_debug_info is unset. > > This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will > print the default ('yes') when the option is unspecified: > > checking if we should zip debug-info files... yes > > What actually took longer than the fix was updating the generated files. We seem to have already settled > on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes > as the system install is 2.69. I was able to get it down to something closer to what is expected by installing > a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated > files for this reason. > > So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference > to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. > > If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. > > Thanks, From gnu.andrew at redhat.com Wed Mar 13 06:58:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 09:58:21 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <5140780F.3050503@oracle.com> Message-ID: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > FWIW we are not tied to autoconf 2.67. There have already been a > number > of pushes using 2.68 and now 2.69 is also showing up. > Yes, Omair was kind enough to point me to this changeset which indeed uses 2.68: http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931 It would be nice to settle on one version though, if the generated file is going to be checked into the repository, otherwise everyone who has a different version installed is going to make lots of spurious changes to that file which obscure the real change. FWIW, gcc also includes the configure file in its Subversion repository and a specific version is used to update it. > David > > On 13/03/2013 10:18 PM, Andrew Hughes wrote: > > I've finally found time to look at the new build system (well, > > there seems to no longer be any choice ;) > > and so thought I start out with a simple fix. > > > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > > > At the moment, if disable-zip-debug-info is not specified, the > > configure output is: > > > > checking if we should zip debug-info files... > > > > with no result as $enable_zip_debug_info is unset. > > > > This simple patch makes the option use the more standard > > AC_ARG_ENABLE form used elsewhere and will > > print the default ('yes') when the option is unspecified: > > > > checking if we should zip debug-info files... yes > > > > What actually took longer than the fix was updating the generated > > files. We seem to have already settled > > on autoconf 2.67 for generating the configure script, so my initial > > attempt threw up a huge number of changes > > as the system install is 2.69. I was able to get it down to > > something closer to what is expected by installing > > a local copy of 2.67 but it's still not perfect. I don't know why. > > I've never been a fan of including generated > > files for this reason. > > > > So this script also updates autogen.sh to see if there is an > > autoconf-2.67 available and use that in preference > > to autoconf if it is. I also added a little debug output so we can > > see which autoconf is being used in autogen.sh. > > > > If this is ok, can you please allocate it a bug ID and let me know > > which tree to commit it to. > > > > Thanks, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Mar 13 07:01:54 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 10:01:54 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <5140811C.4060703@oracle.com> Message-ID: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > I created a bug for you: > > 8009988: build-infra: Fix configure output for zip debuginfo check > > As David says, we haven't decided on 2.67, but I would guess that a > majority of the commits have been with that version. This change is a > first step towards enforcing a specific version and I'm ok with that. Yes, I've been out of the loop a bit on this new build system. When I saw the huge diff my first attempt generated, I just assumed I should be using the same version that had been used previously. > The actual fix looks good to. You will still need a JDK reviewer to > ok > it. Also, please notify me when you push this so that the closed > version > of the configure script may also be regenerated. > Ok, no problem. I await a review from someone like David or Kelly. Is there a preferred tree to push to? I spotted this when just trying to build so it's against jdk8 at the moment (which I obviously can't push to). Perhaps build? > /Erik > > On 2013-03-13 13:18, Andrew Hughes wrote: > > I've finally found time to look at the new build system (well, > > there seems to no longer be any choice ;) > > and so thought I start out with a simple fix. > > > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > > > At the moment, if disable-zip-debug-info is not specified, the > > configure output is: > > > > checking if we should zip debug-info files... > > > > with no result as $enable_zip_debug_info is unset. > > > > This simple patch makes the option use the more standard > > AC_ARG_ENABLE form used elsewhere and will > > print the default ('yes') when the option is unspecified: > > > > checking if we should zip debug-info files... yes > > > > What actually took longer than the fix was updating the generated > > files. We seem to have already settled > > on autoconf 2.67 for generating the configure script, so my initial > > attempt threw up a huge number of changes > > as the system install is 2.69. I was able to get it down to > > something closer to what is expected by installing > > a local copy of 2.67 but it's still not perfect. I don't know why. > > I've never been a fan of including generated > > files for this reason. > > > > So this script also updates autogen.sh to see if there is an > > autoconf-2.67 available and use that in preference > > to autoconf if it is. I also added a little debug output so we can > > see which autoconf is being used in autogen.sh. > > > > If this is ok, can you please allocate it a bug ID and let me know > > which tree to commit it to. > > > > Thanks, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From erik.joelsson at oracle.com Wed Mar 13 07:09:52 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Mar 2013 15:09:52 +0100 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> References: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> Message-ID: <514088B0.3080702@oracle.com> On 2013-03-13 15:01, Andrew Hughes wrote: > ----- Original Message ----- >> Hello, >> >> I created a bug for you: >> >> 8009988: build-infra: Fix configure output for zip debuginfo check >> >> As David says, we haven't decided on 2.67, but I would guess that a >> majority of the commits have been with that version. This change is a >> first step towards enforcing a specific version and I'm ok with that. > Yes, I've been out of the loop a bit on this new build system. > When I saw the huge diff my first attempt generated, I just assumed > I should be using the same version that had been used previously. > >> The actual fix looks good to. You will still need a JDK reviewer to >> ok >> it. Also, please notify me when you push this so that the closed >> version >> of the configure script may also be regenerated. >> > Ok, no problem. I await a review from someone like David or Kelly. > > Is there a preferred tree to push to? I spotted this when just trying > to build so it's against jdk8 at the moment (which I obviously can't push > to). Perhaps build? > Please use jdk8/build. /Erik >> /Erik >> >> On 2013-03-13 13:18, Andrew Hughes wrote: >>> I've finally found time to look at the new build system (well, >>> there seems to no longer be any choice ;) >>> and so thought I start out with a simple fix. >>> >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ >>> >>> At the moment, if disable-zip-debug-info is not specified, the >>> configure output is: >>> >>> checking if we should zip debug-info files... >>> >>> with no result as $enable_zip_debug_info is unset. >>> >>> This simple patch makes the option use the more standard >>> AC_ARG_ENABLE form used elsewhere and will >>> print the default ('yes') when the option is unspecified: >>> >>> checking if we should zip debug-info files... yes >>> >>> What actually took longer than the fix was updating the generated >>> files. We seem to have already settled >>> on autoconf 2.67 for generating the configure script, so my initial >>> attempt threw up a huge number of changes >>> as the system install is 2.69. I was able to get it down to >>> something closer to what is expected by installing >>> a local copy of 2.67 but it's still not perfect. I don't know why. >>> I've never been a fan of including generated >>> files for this reason. >>> >>> So this script also updates autogen.sh to see if there is an >>> autoconf-2.67 available and use that in preference >>> to autoconf if it is. I also added a little debug output so we can >>> see which autoconf is being used in autogen.sh. >>> >>> If this is ok, can you please allocate it a bug ID and let me know >>> which tree to commit it to. >>> >>> Thanks, From gnu.andrew at redhat.com Wed Mar 13 09:16:06 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 12:16:06 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <1461183806.18058801.1363190525156.JavaMail.root@redhat.com> Message-ID: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and so thought it was worth giving some feedback on the problems encountered and issues with the end result: 1. It took some time to work out how to get back to the usual 'noisy' build as the default seems to subdue all the useful output. VERBOSE=true broke the build when it tried to use 'true' as a Makefile target. It turns out the solution is the rather non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have verbosity as a configure option? After grepping around, it's not very obvious to me where it gets set. 2. One of the javac calls in the jdk tree fails with: /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build continues despite this error and the final rt.jar does include JSpinner. 3. -Werror is set for the SCTP native code causing the build to fail: Lots of stuff like: /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) Do we have a preferred way to fix these errors? I know about __unused__ but I believe this is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people like me who go by the usual presumption that the default argument to make is 'all', but appears to have been subverted here. 5. The final image produces: openjdk version "1.8.0-internal" from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, but we've definitely always had 'java version' and not having this will break numerous applications (possibly including the JDK build, as I know at least the old one used to check the version). Hope this helps. I'm happy to produce patches for some of these issues, but wanted to discuss the best way forward first. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Wed Mar 13 10:39:22 2013 From: omajid at redhat.com (Omair Majid) Date: Wed, 13 Mar 2013 13:39:22 -0400 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5140B9CA.2030407@redhat.com> On 03/13/2013 12:16 PM, Andrew Hughes wrote: > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. I ran into this problem as well. I asked on #openjdk and Mike Duigou pointed me to "LOG=trace", which is documented in the build README FAQ [1], although a little hard to find. Cheers, Omair [1] http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#faq -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Mar 13 11:35:09 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 14:35:09 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5140B9CA.2030407@redhat.com> Message-ID: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/13/2013 12:16 PM, Andrew Hughes wrote: > > 1. It took some time to work out how to get back to the usual > > 'noisy' build as the > > default seems to subdue all the useful output. VERBOSE=true broke > > the build when > > it tried to use 'true' as a Makefile target. It turns out the > > solution is the rather > > non-obvious VERBOSE= . Could we not have this documented somewhere > > and perhaps have > > verbosity as a configure option? After grepping around, it's not > > very obvious to me > > where it gets set. > > I ran into this problem as well. I asked on #openjdk and Mike Duigou > pointed me to "LOG=trace", which is documented in the build README > FAQ > [1], although a little hard to find. > Thanks! Ah, I read that document and even that FAQ, but completely missed that as I was looking for something relating to verbosity, not logging which implies (at least to me) that a log will be stored on disk. I still think it should be a configure option, which is the first place I looked. It seems there's still a need to make some options available via configure which are currently only available to make. > Cheers, > Omair > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#faq > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dalibor.topic at oracle.com Wed Mar 13 12:06:14 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 13 Mar 2013 20:06:14 +0100 Subject: Feedback on the New Build System In-Reply-To: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> Message-ID: <5140CE26.3080809@oracle.com> On 3/13/13 7:35 PM, Andrew Hughes wrote: > I still think it should be a configure option, which is the first place I looked. You'd usually use it if something interesting happens, like a build failure, and it's a you're 'not sure how it could have come to this' situation, so in that case, having to re-run configure, and potentially the whole build again seems like a worse option then just adding a variable to the make run as you need it (or not). cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From mike.duigou at oracle.com Wed Mar 13 12:18:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Mar 2013 12:18:23 -0700 Subject: Feedback on the New Build System In-Reply-To: <5140CE26.3080809@oracle.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> <5140CE26.3080809@oracle.com> Message-ID: <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> I generally agree that logging is something I want to tune dynamically. Logging is one of the few things I prefer as an environment variable. As a compromise though perhaps a configure option to adjust the default logging level might work. Still overridable via LOG but with a configurable default. The help documentation could/should also be improved to document "Environment variables which can effect configuration" and "Environment variables which can effect build". These do need to be described separately even if there are some which apply to both. Mike On Mar 13 2013, at 12:06 , Dalibor Topic wrote: > On 3/13/13 7:35 PM, Andrew Hughes wrote: >> I still think it should be a configure option, which is the first place I looked. > > You'd usually use it if something interesting happens, like a build failure, and > it's a you're 'not sure how it could have come to this' situation, so in that case, > having to re-run configure, and potentially the whole build again seems like a worse > option then just adding a variable to the make run as you need it (or not). > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From mike.duigou at oracle.com Wed Mar 13 12:22:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Mar 2013 12:22:29 -0700 Subject: Feedback on the New Build System In-Reply-To: <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> <5140CE26.3080809@oracle.com> <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> Message-ID: <1F95BB4A-936C-413F-850F-4FB06EEEADAB@oracle.com> Ugh. effect -> affect. An unforgivable mistake. Mike On Mar 13 2013, at 12:18 , Mike Duigou wrote: > I generally agree that logging is something I want to tune dynamically. Logging is one of the few things I prefer as an environment variable. > > As a compromise though perhaps a configure option to adjust the default logging level might work. Still overridable via LOG but with a configurable default. > > The help documentation could/should also be improved to document "Environment variables which can effect configuration" and "Environment variables which can effect build". These do need to be described separately even if there are some which apply to both. > > Mike > > > On Mar 13 2013, at 12:06 , Dalibor Topic wrote: > >> On 3/13/13 7:35 PM, Andrew Hughes wrote: >>> I still think it should be a configure option, which is the first place I looked. >> >> You'd usually use it if something interesting happens, like a build failure, and >> it's a you're 'not sure how it could have come to this' situation, so in that case, >> having to re-run configure, and potentially the whole build again seems like a worse >> option then just adding a variable to the make run as you need it (or not). >> >> cheers, >> dalibor topic >> >> -- >> Oracle >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> Oracle Java Platform Group >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> Gesch?ftsf?hrer: J?rgen Kunz >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment > From gnu.andrew at redhat.com Wed Mar 13 12:11:59 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 15:11:59 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5140CE26.3080809@oracle.com> Message-ID: <751822536.18180781.1363201919264.JavaMail.root@redhat.com> ----- Original Message ----- > On 3/13/13 7:35 PM, Andrew Hughes wrote: > > I still think it should be a configure option, which is the first > > place I looked. > > You'd usually use it if something interesting happens, like a build > failure, and > it's a you're 'not sure how it could have come to this' situation, so > in that case, > having to re-run configure, and potentially the whole build again > seems like a worse > option then just adding a variable to the make run as you need it (or > not). > I wasn't suggesting that we replace one with the other, just that configure could be used to pass a setting through to make if requested. It also then means that all the options are documented in one place (./configure --help) rather than some being there, some only in the build README, some not at all, etc. I prefer to run with it always enabled and it worries me that this is no longer the default. It's very easy to suppress information when you don't want it, but it's impossible to produce it if it never existed in the first place. The very people who most need verbose output, when things go wrong, are going to be newbies who won't be aware of this option. Also, failures may be sporadic and not reproducible when you run make again and many of our builds run on remote build systems where it's not a simple case of 'just running make again' to get the output with verbosity. > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed > to developing practices and products that help protect the > environment > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Mar 13 15:13:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 08:13:08 +1000 Subject: Code Review Request: Simple new build system fix In-Reply-To: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> References: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> Message-ID: <5140F9F4.7050502@oracle.com> On 13/03/2013 11:58 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Andrew, >> >> FWIW we are not tied to autoconf 2.67. There have already been a >> number >> of pushes using 2.68 and now 2.69 is also showing up. >> > > Yes, Omair was kind enough to point me to this changeset which indeed > uses 2.68: > > http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931 > > It would be nice to settle on one version though, if the generated file is > going to be checked into the repository, otherwise everyone who has a different > version installed is going to make lots of spurious changes to that file which > obscure the real change. FWIW I rarely pay any attention to the actual generated-configure.sh in doing a review. I only look at the changes to the m4 files etc. There's just too much noise. Any cross-platform build issues will be readily detected, and it's not likely the issues would be recognizable from the source code. Fixing on one version is a problem when so many different machines can be involved in doing the builds. I have 2.68, no matter how I tried I couldn't get it to use the 2.67 that I had installed privately/locally - so I gave up. David ----- > FWIW, gcc also includes the configure file in its Subversion repository and a specific > version is used to update it. > >> David >> >> On 13/03/2013 10:18 PM, Andrew Hughes wrote: >>> I've finally found time to look at the new build system (well, >>> there seems to no longer be any choice ;) >>> and so thought I start out with a simple fix. >>> >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ >>> >>> At the moment, if disable-zip-debug-info is not specified, the >>> configure output is: >>> >>> checking if we should zip debug-info files... >>> >>> with no result as $enable_zip_debug_info is unset. >>> >>> This simple patch makes the option use the more standard >>> AC_ARG_ENABLE form used elsewhere and will >>> print the default ('yes') when the option is unspecified: >>> >>> checking if we should zip debug-info files... yes >>> >>> What actually took longer than the fix was updating the generated >>> files. We seem to have already settled >>> on autoconf 2.67 for generating the configure script, so my initial >>> attempt threw up a huge number of changes >>> as the system install is 2.69. I was able to get it down to >>> something closer to what is expected by installing >>> a local copy of 2.67 but it's still not perfect. I don't know why. >>> I've never been a fan of including generated >>> files for this reason. >>> >>> So this script also updates autogen.sh to see if there is an >>> autoconf-2.67 available and use that in preference >>> to autoconf if it is. I also added a little debug output so we can >>> see which autoconf is being used in autogen.sh. >>> >>> If this is ok, can you please allocate it a bug ID and let me know >>> which tree to commit it to. >>> >>> Thanks, >>> >> > From david.holmes at oracle.com Wed Mar 13 18:26:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 11:26:38 +1000 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5141274E.8060805@oracle.com> Hi Andrew, On 14/03/2013 2:16 AM, Andrew Hughes wrote: > I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and > so thought it was worth giving some feedback on the problems encountered and issues > with the end result: > > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. This has already been covered with LOG=trace (or DEBUG) but note that it is actually logged to disk - the output (regardless of the log level) goes to build.log in the configuration directory (by default). > 2. One of the javac calls in the jdk tree fails with: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist > > This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build > continues despite this error and the final rt.jar does include JSpinner. I think this is actually a javadoc call (hence the non-fatal nature of the error). But it is very hard to associate the message with any given command due to all the interleaving (at least in my build). :( > 3. -Werror is set for the SCTP native code causing the build to fail: > > Lots of stuff like: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] > > as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= > worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) > > Do we have a preferred way to fix these errors? I know about __unused__ but I believe this > is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). What gcc version are you using? I don't see this with 4.6. Probably best to take this up with nio-dev folk. > 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce > a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people > like me who go by the usual presumption that the default argument to make is 'all', but appears to have > been subverted here. This is odd. The top-level Makefile in the forest has: default: all but the generated Makefile in the configuration directory simply includes NewMakefile.gmk which has # This must be the first rule default: I always use the generated Makefile as the entry point but then I never rely on default targets anyway. But this certainly is confusing. > 5. The final image produces: > > openjdk version "1.8.0-internal" > > from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, > but we've definitely always had 'java version' and not having this will break numerous applications (possibly > including the JDK build, as I know at least the old one used to check the version). Is this an old-build vs new-build issue or a 7 vs 8 issue? The default version information comes from files in the forest: ./common/autoconf/version-numbers JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 JDK_UPDATE_VERSION= LAUNCHER_NAME=openjdk PRODUCT_NAME=OpenJDK PRODUCT_SUFFIX="Runtime Environment" JDK_RC_PLATFORM_NAME=Platform COMPANY_NAME=N/A # Might need better names for these MACOSX_BUNDLE_NAME_BASE="OpenJDK" MACOSX_BUNDLE_ID_BASE="net.java.openjdk" Thanks, David > Hope this helps. I'm happy to produce patches for some of these issues, but wanted to discuss the best way > forward first. > > Thanks, > From gnu.andrew at redhat.com Wed Mar 13 19:19:45 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 22:19:45 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <5114CABE.3070809@oracle.com> Message-ID: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> ----- Original Message ----- > The build part of this review looks good to me. > Judging by this changeset, I gather javazic is no longer being run. If so, why is the source code being retained in the tree? It means that a build of OpenJDK against itself now fails. The new build system currently finds the javazic source code and tries to compile it, but fails because ZoneInfoFile.java has changed and Gen.java can no longer compile against it. Deleting the javazic source code fixes the build. Any reason not to commit this? http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > /Erik > > On 2013-02-07 19:31, Xueming Shen wrote: > > Hi, > > > > 8007572: Replace existing jdk timezone data at /lib/zi > > with > > JSR310's tzdb. > > > > Webrev: > > http://cr.openjdk.java.net/~sherman/8007572/ > > > > Note: > > JDK/JRE has been using the time zone data at /lib/zi for > > j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own > > time zone data file/format lib/tzdb.jar to provide the > > time > > zone data support for its new java.time date-time classes. > > > > So we now have two different time zone data files in different > > formats > > (though from the same time zone data source, Olson tz data, now the > > IANA > > Time Zone Datebase) to support two sets of date-time APIs > > (java.util > > date-time classes and java.time date-time classes) in one JDK/JRE, > > which > > definitely will add the maintenance burden going forward, given the > > fact > > that we will have to update/distribute the latest tzdb data in > > JDK/JRE > > periodically [2]. > > > > Also the current way the time-zone data is being > > distributed/installed > > (at /lib.zi, as individual file for each time zone) has > > been > > a footprint concern for some configurations, especially the small > > embedded > > environment. The JEP151 [3] was originally submitted to propose to > > store > > the time-zone data more efficiently into a single compressed file. > > The > > JEP 151 has been withdrawn since, with the assumption that JDK 8 > > may > > replace the "zi" data with the much smaller JSR310 tzdb data file. > > > > As indicated in JEP151, current installed "zi" directory probably > > takes > > up 1M of disk-space with the 0.5k default file-system-block-size. > > Even > > with the proposed "store in one single compressed file" approach, > > it will > > still take about 250K space for all tzdb data in "zi" directory. > > JSR310 > > tzdb data file however is much smaller. It is around 40K for > > compressed > > and 100k uncompressed, for the same tz data. > > > > The proposed change is to share the JSR310 time zone data tzdb.jar > > with j.u.TimeZone by converting the JSR310 tzdb data completely > > (bits > > to bits compatible) at runtime into the internal data structure > > that > > j.u.TimeZone needs for its time zone data functionality/needs. > > > > Thanks! > > -Sherman > > > > [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > > [2] > > http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > > [3] http://openjdk.java.net/jeps/151 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Wed Mar 13 19:51:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Mar 2013 19:51:45 -0700 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> Message-ID: <51413B41.4010305@oracle.com> This should have been addessed via JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job* -Sherman On 3/13/13 7:19 PM, Andrew Hughes wrote: > ----- Original Message ----- >> The build part of this review looks good to me. >> > Judging by this changeset, I gather javazic is no longer being run. > If so, why is the source code being retained in the tree? It means > that a build of OpenJDK against itself now fails. The new > build system currently finds the javazic source code and tries to compile it, > but fails because ZoneInfoFile.java has changed and Gen.java can no longer > compile against it. Deleting the javazic source code fixes the > build. > > Any reason not to commit this? > > http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> /Erik >> >> On 2013-02-07 19:31, Xueming Shen wrote: >>> Hi, >>> >>> 8007572: Replace existing jdk timezone data at /lib/zi >>> with >>> JSR310's tzdb. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sherman/8007572/ >>> >>> Note: >>> JDK/JRE has been using the time zone data at /lib/zi for >>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>> time zone data file/format lib/tzdb.jar to provide the >>> time >>> zone data support for its new java.time date-time classes. >>> >>> So we now have two different time zone data files in different >>> formats >>> (though from the same time zone data source, Olson tz data, now the >>> IANA >>> Time Zone Datebase) to support two sets of date-time APIs >>> (java.util >>> date-time classes and java.time date-time classes) in one JDK/JRE, >>> which >>> definitely will add the maintenance burden going forward, given the >>> fact >>> that we will have to update/distribute the latest tzdb data in >>> JDK/JRE >>> periodically [2]. >>> >>> Also the current way the time-zone data is being >>> distributed/installed >>> (at /lib.zi, as individual file for each time zone) has >>> been >>> a footprint concern for some configurations, especially the small >>> embedded >>> environment. The JEP151 [3] was originally submitted to propose to >>> store >>> the time-zone data more efficiently into a single compressed file. >>> The >>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>> may >>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>> >>> As indicated in JEP151, current installed "zi" directory probably >>> takes >>> up 1M of disk-space with the 0.5k default file-system-block-size. >>> Even >>> with the proposed "store in one single compressed file" approach, >>> it will >>> still take about 250K space for all tzdb data in "zi" directory. >>> JSR310 >>> tzdb data file however is much smaller. It is around 40K for >>> compressed >>> and 100k uncompressed, for the same tz data. >>> >>> The proposed change is to share the JSR310 time zone data tzdb.jar >>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>> (bits >>> to bits compatible) at runtime into the internal data structure >>> that >>> j.u.TimeZone needs for its time zone data functionality/needs. >>> >>> Thanks! >>> -Sherman >>> >>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>> [2] >>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>> [3] http://openjdk.java.net/jeps/151 From tim.bell at oracle.com Wed Mar 13 20:47:10 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 13 Mar 2013 20:47:10 -0700 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <5141483E.5070500@oracle.com> See also the external link to the bug report... http://bugs.sun.com/view_bug.do?bug_id=8008348 > Comments > > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 > User: sherman > Date: 2013-02-17 01:03:19 +0000 HTH- Tim On 03/13/13 19:51, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* > > > -Sherman > > On 3/13/13 7:19 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> The build part of this review looks good to me. >>> >> Judging by this changeset, I gather javazic is no longer being run. >> If so, why is the source code being retained in the tree? It means >> that a build of OpenJDK against itself now fails. The new >> build system currently finds the javazic source code and tries to >> compile it, >> but fails because ZoneInfoFile.java has changed and Gen.java can no >> longer >> compile against it. Deleting the javazic source code fixes the >> build. >> >> Any reason not to commit this? >> >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ >> >>> /Erik >>> >>> On 2013-02-07 19:31, Xueming Shen wrote: >>>> Hi, >>>> >>>> 8007572: Replace existing jdk timezone data at /lib/zi >>>> with >>>> JSR310's tzdb. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sherman/8007572/ >>>> >>>> Note: >>>> JDK/JRE has been using the time zone data at /lib/zi for >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>>> time zone data file/format lib/tzdb.jar to provide the >>>> time >>>> zone data support for its new java.time date-time classes. >>>> >>>> So we now have two different time zone data files in different >>>> formats >>>> (though from the same time zone data source, Olson tz data, now the >>>> IANA >>>> Time Zone Datebase) to support two sets of date-time APIs >>>> (java.util >>>> date-time classes and java.time date-time classes) in one JDK/JRE, >>>> which >>>> definitely will add the maintenance burden going forward, given the >>>> fact >>>> that we will have to update/distribute the latest tzdb data in >>>> JDK/JRE >>>> periodically [2]. >>>> >>>> Also the current way the time-zone data is being >>>> distributed/installed >>>> (at /lib.zi, as individual file for each time zone) has >>>> been >>>> a footprint concern for some configurations, especially the small >>>> embedded >>>> environment. The JEP151 [3] was originally submitted to propose to >>>> store >>>> the time-zone data more efficiently into a single compressed file. >>>> The >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>>> may >>>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>>> >>>> As indicated in JEP151, current installed "zi" directory probably >>>> takes >>>> up 1M of disk-space with the 0.5k default file-system-block-size. >>>> Even >>>> with the proposed "store in one single compressed file" approach, >>>> it will >>>> still take about 250K space for all tzdb data in "zi" directory. >>>> JSR310 >>>> tzdb data file however is much smaller. It is around 40K for >>>> compressed >>>> and 100k uncompressed, for the same tz data. >>>> >>>> The proposed change is to share the JSR310 time zone data tzdb.jar >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>>> (bits >>>> to bits compatible) at runtime into the internal data structure >>>> that >>>> j.u.TimeZone needs for its time zone data functionality/needs. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>>> [2] >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>>> >>>> [3] http://openjdk.java.net/jeps/151 > From david.holmes at oracle.com Wed Mar 13 21:26:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 14:26:28 +1000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <51415174.5010309@oracle.com> On 14/03/2013 12:51 PM, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* Which is still in the tl repo and unlikely to reach jdk8/jdk8 till b82 promotion next week. David > -Sherman > > On 3/13/13 7:19 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> The build part of this review looks good to me. >>> >> Judging by this changeset, I gather javazic is no longer being run. >> If so, why is the source code being retained in the tree? It means >> that a build of OpenJDK against itself now fails. The new >> build system currently finds the javazic source code and tries to >> compile it, >> but fails because ZoneInfoFile.java has changed and Gen.java can no >> longer >> compile against it. Deleting the javazic source code fixes the >> build. >> >> Any reason not to commit this? >> >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ >> >>> /Erik >>> >>> On 2013-02-07 19:31, Xueming Shen wrote: >>>> Hi, >>>> >>>> 8007572: Replace existing jdk timezone data at /lib/zi >>>> with >>>> JSR310's tzdb. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sherman/8007572/ >>>> >>>> Note: >>>> JDK/JRE has been using the time zone data at /lib/zi for >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>>> time zone data file/format lib/tzdb.jar to provide the >>>> time >>>> zone data support for its new java.time date-time classes. >>>> >>>> So we now have two different time zone data files in different >>>> formats >>>> (though from the same time zone data source, Olson tz data, now the >>>> IANA >>>> Time Zone Datebase) to support two sets of date-time APIs >>>> (java.util >>>> date-time classes and java.time date-time classes) in one JDK/JRE, >>>> which >>>> definitely will add the maintenance burden going forward, given the >>>> fact >>>> that we will have to update/distribute the latest tzdb data in >>>> JDK/JRE >>>> periodically [2]. >>>> >>>> Also the current way the time-zone data is being >>>> distributed/installed >>>> (at /lib.zi, as individual file for each time zone) has >>>> been >>>> a footprint concern for some configurations, especially the small >>>> embedded >>>> environment. The JEP151 [3] was originally submitted to propose to >>>> store >>>> the time-zone data more efficiently into a single compressed file. >>>> The >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>>> may >>>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>>> >>>> As indicated in JEP151, current installed "zi" directory probably >>>> takes >>>> up 1M of disk-space with the 0.5k default file-system-block-size. >>>> Even >>>> with the proposed "store in one single compressed file" approach, >>>> it will >>>> still take about 250K space for all tzdb data in "zi" directory. >>>> JSR310 >>>> tzdb data file however is much smaller. It is around 40K for >>>> compressed >>>> and 100k uncompressed, for the same tz data. >>>> >>>> The proposed change is to share the JSR310 time zone data tzdb.jar >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>>> (bits >>>> to bits compatible) at runtime into the internal data structure >>>> that >>>> j.u.TimeZone needs for its time zone data functionality/needs. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>>> [2] >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>>> >>>> [3] http://openjdk.java.net/jeps/151 > From Alan.Bateman at oracle.com Wed Mar 13 23:47:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 06:47:09 +0000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <5141726D.2090107@oracle.com> On 14/03/2013 02:51, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* > > Right, this was fixed several weeks ago with: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 There are a lot of changes backed up in jdk8/tl due to several issues. Lana Steuck will be integrating them into jdk8/jdk8 soon. -Alan. From Alan.Bateman at oracle.com Thu Mar 14 01:58:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 08:58:49 +0000 Subject: Feedback on the New Build System In-Reply-To: <5141274E.8060805@oracle.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> <5141274E.8060805@oracle.com> Message-ID: <51419149.2070204@oracle.com> On 14/03/2013 01:26, David Holmes wrote: > : > >> 3. -Werror is set for the SCTP native code causing the build to fail: >> >> Lots of stuff like: >> >> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >> error: unused parameter 'klass' [-Werror=unused-parameter] >> >> as -Werror is passed and -Wno-unused doesn't seem to turn these off. >> SCTP_WERROR= >> worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS >> to match HotSpot?) >> >> Do we have a preferred way to fix these errors? I know about >> __unused__ but I believe this >> is GCC-specific and I wouldn't want to break the build on other >> platforms (Solaris, MacOS X, BSD). > > What gcc version are you using? I don't see this with 4.6. > > Probably best to take this up with nio-dev folk. I'm using 4.6.3 and don't see it either. In any case, this is SCTP so net-dev is the best place to review a patch to it (but it doesn't matter, the right people will see it either way). -Alan From erik.joelsson at oracle.com Thu Mar 14 02:11:27 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Mar 2013 10:11:27 +0100 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5141943F.9080200@oracle.com> Hello Andrew, Thanks for the feedback! Adding in my view of things below. On 2013-03-13 17:16, Andrew Hughes wrote: > I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and > so thought it was worth giving some feedback on the problems encountered and issues > with the end result: > > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. > As already pointed out, the preferred way is to use LOG=warn/info/debug/trace, where "debug" best matches what the old build did. I don't recommend trace for normal use. The default level tries to keep the user informed about what is happening without information overload. It also makes warning messages stand out more in the hope that it annoys someone enough to go fix them. I agree that adding a configure option for changing the default is a good idea and would welcome such a patch. Internally we encourage using "debug" for nightly/remote builds. The build output is also saved to build.log in the configure directory as David said. > 2. One of the javac calls in the jdk tree fails with: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist > > This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build > continues despite this error and the final rt.jar does include JSpinner. > It's actually not javac, but probably javadoc as David said, and is part of java source generation. I'm guessing it's the swing beans (dt.jar) that previously were generated at image creation time. It seems harmless though, but perhaps it needs to be investigated. > 3. -Werror is set for the SCTP native code causing the build to fail: > > Lots of stuff like: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] > > as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= > worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) > > Do we have a preferred way to fix these errors? I know about __unused__ but I believe this > is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). > This I have not noticed. Is it specific to some GCC version? > 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce > a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people > like me who go by the usual presumption that the default argument to make is 'all', but appears to have > been subverted here. > I can agree that it's a bit odd. It was done this way early on to reduce build times for the average developer who usually isn't interested in images and certainly not docs. For openjdk, we have "default" which translates to "jdk" and "all" which translates to "images docs". One could argue that the developer wanting to save time could type "make jdk" instead, but then, the developer wanting save time probably just wants to type "make". The root Makefile is still the old build, but the first thing it does is calling NewMakefile.gmk unless NEWBUILD=false is set. When we finally remove the old build system, NewMakefile.gmk will replace Makefile in the root. > 5. The final image produces: > > openjdk version "1.8.0-internal" > > from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, > but we've definitely always had 'java version' and not having this will break numerous applications (possibly > including the JDK build, as I know at least the old one used to check the version). > AFAIK this is the same with the old build. We have certainly not tried to change it. If you need additional configure logic to change or remove that string that isn't already there, that shouldn't be a problem. /Erik From chris.hegarty at oracle.com Thu Mar 14 03:03:49 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Mar 2013 10:03:49 +0000 Subject: Feedback on the New Build System In-Reply-To: <51419149.2070204@oracle.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> <5141274E.8060805@oracle.com> <51419149.2070204@oracle.com> Message-ID: <5141A085.9050803@oracle.com> On 03/14/2013 08:58 AM, Alan Bateman wrote: > On 14/03/2013 01:26, David Holmes wrote: >> : >> >>> 3. -Werror is set for the SCTP native code causing the build to fail: >>> >>> Lots of stuff like: >>> >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >>> error: unused parameter 'klass' [-Werror=unused-parameter] >>> >>> as -Werror is passed and -Wno-unused doesn't seem to turn these off. >>> SCTP_WERROR= >>> worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS >>> to match HotSpot?) >>> >>> Do we have a preferred way to fix these errors? I know about >>> __unused__ but I believe this >>> is GCC-specific and I wouldn't want to break the build on other >>> platforms (Solaris, MacOS X, BSD). >> >> What gcc version are you using? I don't see this with 4.6. >> >> Probably best to take this up with nio-dev folk. > I'm using 4.6.3 and don't see it either. In any case, this is SCTP so > net-dev is the best place to review a patch to it (but it doesn't > matter, the right people will see it either way). I've not seen issues with SCTP compiles either. That said, the SCTP native code should be clean, where possible, from all warnings ( unless something has changed recently ). >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >>> error: unused parameter 'klass' [-Werror=unused-parameter] The above specific warning cannot be fixed in the code as the unused parameter is part of the JNI method declaration. If these are the only type of warnings in this area, and they cause the build to fail, then it is a build issue and not a source one. -Chris. > > -Alan From gnu.andrew at redhat.com Thu Mar 14 09:10:14 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 12:10:14 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51415174.5010309@oracle.com> Message-ID: <155408043.18863217.1363277414103.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 12:51 PM, Xueming Shen wrote: > > This should have been addessed via > > > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build > > problems > > with hs25-b19 control job* > > > > Which is still in the tl repo and unlikely to reach jdk8/jdk8 till > b82 > promotion next week. > Yep, that's exactly why I'm seeing it. This is in an IcedTea build using the latest build drop, b80. Glad it's been caught and dealt with :) > David > > > -Sherman > > > > On 3/13/13 7:19 PM, Andrew Hughes wrote: > >> ----- Original Message ----- > >>> The build part of this review looks good to me. > >>> > >> Judging by this changeset, I gather javazic is no longer being > >> run. > >> If so, why is the source code being retained in the tree? It > >> means > >> that a build of OpenJDK against itself now fails. The new > >> build system currently finds the javazic source code and tries to > >> compile it, > >> but fails because ZoneInfoFile.java has changed and Gen.java can > >> no > >> longer > >> compile against it. Deleting the javazic source code fixes the > >> build. > >> > >> Any reason not to commit this? > >> > >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> > >>> /Erik > >>> > >>> On 2013-02-07 19:31, Xueming Shen wrote: > >>>> Hi, > >>>> > >>>> 8007572: Replace existing jdk timezone data at > >>>> /lib/zi > >>>> with > >>>> JSR310's tzdb. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~sherman/8007572/ > >>>> > >>>> Note: > >>>> JDK/JRE has been using the time zone data at /lib/zi > >>>> for > >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its > >>>> own > >>>> time zone data file/format lib/tzdb.jar to provide > >>>> the > >>>> time > >>>> zone data support for its new java.time date-time classes. > >>>> > >>>> So we now have two different time zone data files in different > >>>> formats > >>>> (though from the same time zone data source, Olson tz data, now > >>>> the > >>>> IANA > >>>> Time Zone Datebase) to support two sets of date-time APIs > >>>> (java.util > >>>> date-time classes and java.time date-time classes) in one > >>>> JDK/JRE, > >>>> which > >>>> definitely will add the maintenance burden going forward, given > >>>> the > >>>> fact > >>>> that we will have to update/distribute the latest tzdb data in > >>>> JDK/JRE > >>>> periodically [2]. > >>>> > >>>> Also the current way the time-zone data is being > >>>> distributed/installed > >>>> (at /lib.zi, as individual file for each time zone) > >>>> has > >>>> been > >>>> a footprint concern for some configurations, especially the > >>>> small > >>>> embedded > >>>> environment. The JEP151 [3] was originally submitted to propose > >>>> to > >>>> store > >>>> the time-zone data more efficiently into a single compressed > >>>> file. > >>>> The > >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 > >>>> may > >>>> replace the "zi" data with the much smaller JSR310 tzdb data > >>>> file. > >>>> > >>>> As indicated in JEP151, current installed "zi" directory > >>>> probably > >>>> takes > >>>> up 1M of disk-space with the 0.5k default > >>>> file-system-block-size. > >>>> Even > >>>> with the proposed "store in one single compressed file" > >>>> approach, > >>>> it will > >>>> still take about 250K space for all tzdb data in "zi" directory. > >>>> JSR310 > >>>> tzdb data file however is much smaller. It is around 40K for > >>>> compressed > >>>> and 100k uncompressed, for the same tz data. > >>>> > >>>> The proposed change is to share the JSR310 time zone data > >>>> tzdb.jar > >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely > >>>> (bits > >>>> to bits compatible) at runtime into the internal data structure > >>>> that > >>>> j.u.TimeZone needs for its time zone data functionality/needs. > >>>> > >>>> Thanks! > >>>> -Sherman > >>>> > >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > >>>> [2] > >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > >>>> > >>>> [3] http://openjdk.java.net/jeps/151 > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 10:26:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:26:21 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <51419149.2070204@oracle.com> Message-ID: <1642314789.18941210.1363281981694.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 01:26, David Holmes wrote: > > : > > > >> 3. -Werror is set for the SCTP native code causing the build to > >> fail: > >> > >> Lots of stuff like: > >> > >> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > >> error: unused parameter 'klass' [-Werror=unused-parameter] > >> > >> as -Werror is passed and -Wno-unused doesn't seem to turn these > >> off. > >> SCTP_WERROR= > >> worked around it (perhaps this should at least be > >> WARNINGS_ARE_ERRORS > >> to match HotSpot?) > >> > >> Do we have a preferred way to fix these errors? I know about > >> __unused__ but I believe this > >> is GCC-specific and I wouldn't want to break the build on other > >> platforms (Solaris, MacOS X, BSD). > > > > What gcc version are you using? I don't see this with 4.6. > > > > Probably best to take this up with nio-dev folk. > I'm using 4.6.3 and don't see it either. In any case, this is SCTP so > net-dev is the best place to review a patch to it (but it doesn't > matter, the right people will see it either way). > Yeah, I'll take a patch to the right group if it's warranted. I just wanted to know whether it was generally something we fix and if so, how? This is with the upcoming 4.8.0 release which is why I'm seeing it locally and Omair's seeing it on Fedora 19/rawhide builds i.e. we're catching it early ;) > -Alan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 10:28:02 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:28:02 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5141A085.9050803@oracle.com> Message-ID: <822116354.18941678.1363282082510.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/14/2013 08:58 AM, Alan Bateman wrote: > > On 14/03/2013 01:26, David Holmes wrote: > >> : > >> > >>> 3. -Werror is set for the SCTP native code causing the build to > >>> fail: > >>> > >>> Lots of stuff like: > >>> > >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > >>> error: unused parameter 'klass' [-Werror=unused-parameter] > >>> > >>> as -Werror is passed and -Wno-unused doesn't seem to turn these > >>> off. > >>> SCTP_WERROR= > >>> worked around it (perhaps this should at least be > >>> WARNINGS_ARE_ERRORS > >>> to match HotSpot?) > >>> > >>> Do we have a preferred way to fix these errors? I know about > >>> __unused__ but I believe this > >>> is GCC-specific and I wouldn't want to break the build on other > >>> platforms (Solaris, MacOS X, BSD). > >> > >> What gcc version are you using? I don't see this with 4.6. > >> > >> Probably best to take this up with nio-dev folk. > > I'm using 4.6.3 and don't see it either. In any case, this is SCTP > > so > > net-dev is the best place to review a patch to it (but it doesn't > > matter, the right people will see it either way). > > I've not seen issues with SCTP compiles either. That said, the SCTP > native code should be clean, where possible, from all warnings ( > unless > something has changed recently ). > > >>> > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > > >>> error: unused parameter 'klass' [-Werror=unused-parameter] > > The above specific warning cannot be fixed in the code as the unused > parameter is part of the JNI method declaration. If these are the > only > type of warnings in this area, and they cause the build to fail, then > it > is a build issue and not a source one. > > -Chris. > > > > > -Alan > The general issue, and one I've pointed out for HotSpot before, is don't turn on -Werror for everyone. It inevitably breaks someone's build somewhere at sometime. I believe you can use __unused__ on the parameters, but that's probably GCC-specific. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Thu Mar 14 16:46:45 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 19:46:45 -0400 Subject: Any support for not stripping binaries? Message-ID: <51426165.8020407@redhat.com> Hi, I was wondering if there a known way to avoid stripping binaries? I tried the following configuration $ bash configure --enable-debug --disable-zip-debug-info $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip DEBUG_BINARIES=true all The hotspot shared objects (such as libjvm.so, libjsgi.so, libattach.so) still had DWARF information, but all JDK shared objects (such as the java launcher, libawt.so) seem to be stripped. Is there a way to emulate this style of the builds? $ make DEBUG_CLASSFILES="true" \ DEBUG_BINARIES="true" \ STRIP_POLICY="no_strip" Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.holmes at oracle.com Thu Mar 14 18:36:06 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 11:36:06 +1000 Subject: Any support for not stripping binaries? In-Reply-To: <51426165.8020407@redhat.com> References: <51426165.8020407@redhat.com> Message-ID: <51427B06.3090700@oracle.com> On 15/03/2013 9:46 AM, Omair Majid wrote: > Hi, > > I was wondering if there a known way to avoid stripping binaries? > > I tried the following configuration > $ bash configure --enable-debug --disable-zip-debug-info > $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip DEBUG_BINARIES=true all > > The hotspot shared objects (such as libjvm.so, libjsgi.so, libattach.so) > still had DWARF information, but all JDK shared objects (such as the > java launcher, libawt.so) seem to be stripped. > > Is there a way to emulate this style of the builds? > > $ make > DEBUG_CLASSFILES="true" \ > DEBUG_BINARIES="true" \ > STRIP_POLICY="no_strip" It appears not. STRIP_POLICY is not used on the jdk side of the build any more (why? accidental omission in the conversion?) - though I found it somewhat dubious anyway. There's a tension between what to put in in the first place, versus what to strip out later. Eg creating libs with all symbols can be useful for debugging, but the final image can have them stripped out. Problem then is that you need vastly more disk space during the build. Given that POST_STRIP_COMMAND= on the make invocation should nullify post-stripping, I'm wondering if the problem is with what is getting built in in the first place? And as you note hotspot deals with this it's own, potentially incompatible, way. David ----- > Thanks, > Omair > From gnu.andrew at redhat.com Thu Mar 14 20:46:42 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 23:46:42 -0400 (EDT) Subject: Any support for not stripping binaries? In-Reply-To: <51427B06.3090700@oracle.com> Message-ID: <1239452366.19118998.1363319202050.JavaMail.root@redhat.com> ----- Original Message ----- > On 15/03/2013 9:46 AM, Omair Majid wrote: > > Hi, > > > > I was wondering if there a known way to avoid stripping binaries? > > > > I tried the following configuration > > $ bash configure --enable-debug --disable-zip-debug-info > > $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip DEBUG_BINARIES=true > > all > > > > The hotspot shared objects (such as libjvm.so, libjsgi.so, > > libattach.so) > > still had DWARF information, but all JDK shared objects (such as > > the > > java launcher, libawt.so) seem to be stripped. > > > > Is there a way to emulate this style of the builds? > > > > $ make > > DEBUG_CLASSFILES="true" \ > > DEBUG_BINARIES="true" \ > > STRIP_POLICY="no_strip" > > It appears not. STRIP_POLICY is not used on the jdk side of the build > any more (why? accidental omission in the conversion?) - though I > found > it somewhat dubious anyway. There's a tension between what to put in > in > the first place, versus what to strip out later. Eg creating libs > with > all symbols can be useful for debugging, but the final image can have > them stripped out. Problem then is that you need vastly more disk > space > during the build. > > Given that POST_STRIP_COMMAND= on the make invocation should nullify > post-stripping, I'm wondering if the problem is with what is getting > built in in the first place? > > And as you note hotspot deals with this it's own, potentially > incompatible, way. > It still seems to be using STRIP_POLICY, at least in b80. jdk/make/common/Library.gmk has: ifeq ($(STRIP_POLICY),all_strip) $(STRIP) $@ else ifeq ($(STRIP_POLICY),min_strip) ifeq ($(PLATFORM), solaris) $(STRIP) -x $@ else # assume Linux $(STRIP) -g $@ endif # implied else here is no stripping at all endif endif though this may be part of the old build and dead, as it seems to be duplicated in common/makefiles/NativeCompilation.gmk, There's a bug in that debuginfo files are always created, but that is true in 7 too (and something we patched locally in IcedTea for now, I think). I noticed that some JDK libraries have debuginfo files and some don't, so I compared libhprof with libawt. And guess what? libhprof's invocation of SetupNativeCompilation has DEBUG_SYMBOLS:=true while libawt's doesn't. common/makefiles/NativeCompilation.gmk has: ifneq (,$$($1_DEBUG_SYMBOLS)) ifeq ($(ENABLE_DEBUG_SYMBOLS), true) # Programs don't get the debug symbols added in the old build. It's not clear if # this is intentional. ifeq ($$($1_PROGRAM),) $1_EXTRA_CFLAGS+=$(CFLAGS_DEBUG_SYMBOLS) $1_EXTRA_CXXFLAGS+=$(CXXFLAGS_DEBUG_SYMBOLS) endif endif endif I don't see why we need two checks for enabling debug symbols. At the very least, the default should be on. As a quick fix, the outer conditional could be removed. > David > ----- > > > Thanks, > > Omair > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Thu Mar 14 21:24:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 14:24:54 +1000 Subject: Any support for not stripping binaries? In-Reply-To: <1239452366.19118998.1363319202050.JavaMail.root@redhat.com> References: <1239452366.19118998.1363319202050.JavaMail.root@redhat.com> Message-ID: <5142A296.8040202@oracle.com> On 15/03/2013 1:46 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 15/03/2013 9:46 AM, Omair Majid wrote: >>> >>> I was wondering if there a known way to avoid stripping binaries? >>> >>> I tried the following configuration >>> $ bash configure --enable-debug --disable-zip-debug-info >>> $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip DEBUG_BINARIES=true >>> all >>> >>> The hotspot shared objects (such as libjvm.so, libjsgi.so, >>> libattach.so) >>> still had DWARF information, but all JDK shared objects (such as >>> the >>> java launcher, libawt.so) seem to be stripped. >>> >>> Is there a way to emulate this style of the builds? >>> >>> $ make >>> DEBUG_CLASSFILES="true" \ >>> DEBUG_BINARIES="true" \ >>> STRIP_POLICY="no_strip" >> >> It appears not. STRIP_POLICY is not used on the jdk side of the build >> any more (why? accidental omission in the conversion?) - though I >> found >> it somewhat dubious anyway. There's a tension between what to put in >> in >> the first place, versus what to strip out later. Eg creating libs >> with >> all symbols can be useful for debugging, but the final image can have >> them stripped out. Problem then is that you need vastly more disk >> space >> during the build. >> >> Given that POST_STRIP_COMMAND= on the make invocation should nullify >> post-stripping, I'm wondering if the problem is with what is getting >> built in in the first place? >> >> And as you note hotspot deals with this it's own, potentially >> incompatible, way. >> > > It still seems to be using STRIP_POLICY, at least in b80. > jdk/make/common/Library.gmk has: That is the old build. > There's a bug in that debuginfo files are always created, but that > is true in 7 too (and something we patched locally in IcedTea for now, > I think). > > I noticed that some JDK libraries have debuginfo files and some don't, > so I compared libhprof with libawt. And guess what? libhprof's > invocation of SetupNativeCompilation has DEBUG_SYMBOLS:=true > while libawt's doesn't. The Full Debug Symbol project had limited scope as to which libraries/binaries symbols were to be produced for and for which platforms - Dan Daugherty has covered this a couple of times in related email threads (sorry no quick cross-reference). As was mentioned in those other threads we need to distinguish between Oracle JDK FDS needs and OpenJDK FDS needed. > common/makefiles/NativeCompilation.gmk has: > > ifneq (,$$($1_DEBUG_SYMBOLS)) > ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > # Programs don't get the debug symbols added in the old build. It's not clear if > # this is intentional. > ifeq ($$($1_PROGRAM),) > $1_EXTRA_CFLAGS+=$(CFLAGS_DEBUG_SYMBOLS) > $1_EXTRA_CXXFLAGS+=$(CXXFLAGS_DEBUG_SYMBOLS) > endif > endif > endif > > I don't see why we need two checks for enabling debug symbols. At the very least, > the default should be on. There is currently a per-library setting and a global setting. The per-library settings are as per the scope of the FDS project just mentioned. Executables are excluded. Long history here and it needs cleaning up in a way that will meet the needs of different builders of the OpenJDK sources. David ----- > > As a quick fix, the outer conditional could be removed. > >> David >> ----- >> >>> Thanks, >>> Omair >>> >> > From gnu.andrew at redhat.com Fri Mar 15 11:08:24 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Mar 2013 14:08:24 -0400 (EDT) Subject: Any support for not stripping binaries? In-Reply-To: <5142A296.8040202@oracle.com> Message-ID: <220840795.19472252.1363370904812.JavaMail.root@redhat.com> ----- Original Message ----- > On 15/03/2013 1:46 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 15/03/2013 9:46 AM, Omair Majid wrote: > >>> > >>> I was wondering if there a known way to avoid stripping binaries? > >>> > >>> I tried the following configuration > >>> $ bash configure --enable-debug --disable-zip-debug-info > >>> $ make POST_STRIP_CMD='' STRIP_POLICY=no_strip > >>> DEBUG_BINARIES=true > >>> all > >>> > >>> The hotspot shared objects (such as libjvm.so, libjsgi.so, > >>> libattach.so) > >>> still had DWARF information, but all JDK shared objects (such as > >>> the > >>> java launcher, libawt.so) seem to be stripped. > >>> > >>> Is there a way to emulate this style of the builds? > >>> > >>> $ make > >>> DEBUG_CLASSFILES="true" \ > >>> DEBUG_BINARIES="true" \ > >>> STRIP_POLICY="no_strip" > >> > >> It appears not. STRIP_POLICY is not used on the jdk side of the > >> build > >> any more (why? accidental omission in the conversion?) - though I > >> found > >> it somewhat dubious anyway. There's a tension between what to put > >> in > >> in > >> the first place, versus what to strip out later. Eg creating libs > >> with > >> all symbols can be useful for debugging, but the final image can > >> have > >> them stripped out. Problem then is that you need vastly more disk > >> space > >> during the build. > >> > >> Given that POST_STRIP_COMMAND= on the make invocation should > >> nullify > >> post-stripping, I'm wondering if the problem is with what is > >> getting > >> built in in the first place? > >> > >> And as you note hotspot deals with this it's own, potentially > >> incompatible, way. > >> > > > > It still seems to be using STRIP_POLICY, at least in b80. > > jdk/make/common/Library.gmk has: > > That is the old build. > Yeah, I was looking into it while writing the e-mail and sort of realised this halfway through... Is there a reason this is still even present? It's confusing. > > There's a bug in that debuginfo files are always created, but that > > is true in 7 too (and something we patched locally in IcedTea for > > now, > > I think). > > > > I noticed that some JDK libraries have debuginfo files and some > > don't, > > so I compared libhprof with libawt. And guess what? libhprof's > > invocation of SetupNativeCompilation has DEBUG_SYMBOLS:=true > > while libawt's doesn't. > > The Full Debug Symbol project had limited scope as to which > libraries/binaries symbols were to be produced for and for which > platforms - Dan Daugherty has covered this a couple of times in > related > email threads (sorry no quick cross-reference). > I remember the discussion a little. > As was mentioned in those other threads we need to distinguish > between > Oracle JDK FDS needs and OpenJDK FDS needed. > > > common/makefiles/NativeCompilation.gmk has: > > > > ifneq (,$$($1_DEBUG_SYMBOLS)) > > ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > > # Programs don't get the debug symbols added in the > > old build. It's not clear if > > # this is intentional. > > ifeq ($$($1_PROGRAM),) > > $1_EXTRA_CFLAGS+=$(CFLAGS_DEBUG_SYMBOLS) > > $1_EXTRA_CXXFLAGS+=$(CXXFLAGS_DEBUG_SYMBOLS) > > endif > > endif > > endif > > > > I don't see why we need two checks for enabling debug symbols. At > > the very least, > > the default should be on. > > There is currently a per-library setting and a global setting. The > per-library settings are as per the scope of the FDS project just > mentioned. Executables are excluded. > > Long history here and it needs cleaning up in a way that will meet > the > needs of different builders of the OpenJDK sources. > As a first suggestion, could we make the first conditional here only happen on non-OpenJDK builds? I don't see any reason why OpenJDK builds shouldn't have debugging information for all libraries, if requested. > David > ----- > > > > > As a quick fix, the outer conditional could be removed. > > > >> David > >> ----- > >> > >>> Thanks, > >>> Omair > >>> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sadhak001 at gmail.com Wed Mar 20 03:51:35 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 20 Mar 2013 10:51:35 +0000 Subject: Building on Mac (David DeHaven) In-Reply-To: <5146CE31.7090005@oracle.com> References: <5146CE31.7090005@oracle.com> Message-ID: Hi Erik, Thanks for those tips, I have update the pages. They worked as expected on both my Ubuntu and MacOS machines. Didn't try it on Windows but I take its universal. I took a look at the build logs after running it with the LOG=warn option, and saw a number of GCC warning messages. Surprisingly these are down big-time, but I did see a whole bunch of news ones. Have these been cleaned up as per of internal warnings removal efforts? When I tried the *make clean images LOG=trace* on my Ubuntu machine it worked fine but didn't work when I ran it on my MacOS X 10.7 Lion: /Users/swami/sources/jdk8_tl//common/makefiles/Main.gmk:43: Running shell command /usr/bin/time: illegal option -- f usage: time [-lp] command. /Users/swami/sources/jdk8_tl//common/makefiles/Main.gmk:44: Running shell command /usr/bin/time: illegal option -- f usage: time [-lp] command. /Users/swami/sources/jdk8_tl//common/makefiles/Main.gmk:48: Running shell command /usr/bin/time: illegal option -- f usage: time [-lp] command. /Users/swami/sources/jdk8_tl//common/makefiles/Main.gmk:57: Running shell command /usr/bin/time: illegal option -- f usage: time [-lp] command. /Users/swami/sources/jdk8_tl//common/makefiles/Main.gmk:219: Building clean-langtools /usr/bin/time: illegal option -- f usage: time [-lp] command. make: *** [clean-langtools] Error 1 I did make sure had the latest source (getsource) and also ran bash configure before re-running the same command and got the same results. Any ideas? Cheers, mani On Mon, Mar 18, 2013 at 8:20 AM, Erik Joelsson wrote: > A few comments inline. > > > On 2013-03-16 21:38, Mani Sarkar wrote: > >> Hi, >> >> The OpenJDK adopters in the community have been testing out >> the steps lately to build OpenJDK on the MacOS and so far things are fine, >> we didn't need to install MacPort or have major issues with the Mac. >> >> You can have a look at the steps if these help with your issues: >> http://java.net/projects/**adoptopenjdk/pages/** >> AdoptOpenJDKBuildInstructions >> http://java.net/projects/**adoptopenjdk/pages/GetSource >> http://java.net/projects/**adoptopenjdk/pages/GetSource#**Mac_OS_X >> http://java.net/projects/**adoptopenjdk/pages/Build#Mac_**OS_X >> > There is no need to cd down to common/makefiles anymore. We hid the new > build system there before making it default. Now you can run bash configure > and make from the root. Please see README-builds.html in the src root for > more details. It should be up to date now, thanks to Kelly. > >> http://java.net/projects/**adoptopenjdk/pages/MakeImages >> >> To get verbose build logs, the preferred way is to use the LOG variable > and not VERBOSE. LOG can be set to warn, info, debug or trace. Again see > README-builds.html. Also, the build output is always saved to a log file in > the build output directory unless disabled, so no need to pipe yourself. > > /Erik > > Any feedback is welcome. >> >> Cheers, >> mani >> >> >> It's not installed by default, and I'm not sure why you'd want to since >>>>> >>>> Apple provides it. But if it's there that could be a concern. >>> >>>> If you install subversion, you get file, and there are other things that >>>> >>> (if installed) will pull in subversion (e.g., trac). >>> >>> Ah Trac, how I remember thee... >>> >>> >>> Incidentally, someone else got a build working with brew so there's an >>>>> >>>> alternative to MacPorts for those who don't want to use it. The only >>> caveat >>> is that brew installs everything into the system paths, which could cause >>> problems later on. And it uses Ruby *hack cough*... >>> >>>> Installing stuff on system paths is not what I want. >>>> >>> Same here, which is one reason I stick with MacPorts. I'm not sure what >>> the fuss is anyways, once binaries are available ports come in very fast. >>> >>> -DrD- >>> >>> -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From andy.herrick at oracle.com Sun Mar 24 16:00:46 2013 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 24 Mar 2013 19:00:46 -0400 Subject: Setup JDK Build on Mac with new build infrastructure In-Reply-To: <514F631E.4020508@oracle.com> References: <5149D0AA.1050000@oracle.com> <499E465B-04F7-4746-94F4-5839FD442FBE@oracle.com> <5149D500.8000607@oracle.com> <5149E6B3.9090602@oracle.com> <5149E982.5070602@oracle.com> <514F631E.4020508@oracle.com> Message-ID: <514F859E.9000901@oracle.com> On 3/24/2013 4:33 PM, Andy Herrick wrote: > OK - Now using the new build infrastructure on MacOSX - and I can > build with no errors, but is not building deploy and install. > I am using configuration generated by: > bash configure > --with-junit-dir=/Users/aherrick/java/devtools/share/junit/latest > --with-devtools-path=/Users/aherrick/java/devtools > --with-mozilla-headers=/Users/aherrick/java/devtools/share/plugin > --with-sparkle-framework=/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6 > --with-javafx-zip-dir= > > the config log is attached. > > It seems to find the closed code and so is not trying to build openJDK > , but it may be building new server jdk. > > anyone know how to build everything ? > > /Andy > > -------------- next part -------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by OpenJDK configure jdk8, which was generated by GNU Autoconf 2.67. Invocation command line was $ ./common/autoconf/configure --enable-option-checking=fatal --with-junit-dir=/Users/aherrick/java/devtools/share/junit/latest --with-devtools-path=/Users/aherrick/java/devtools --with-mozilla-headers=/Users/aherrick/java/devtools/share/plugin --with-sparkle-framework=/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6 --with-javafx-zip-dir= ## --------- ## ## Platform. ## ## --------- ## hostname = sharks uname -m = x86_64 uname -r = 11.4.2 uname -s = Darwin uname -v = Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = Mach kernel version: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 Kernel configured for up to 2 processors. 2 processors are physically available. 2 processors are logically available. Processor type: i486 (Intel 80486) Processors active: 0 1 Primary memory available: 4.00 gigabytes Default processor set: 87 tasks, 394 threads, 2 processors Load average: 0.26, Mach factor: 1.72 /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /usr/X11/bin PATH: /usr/X11/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:3947: Configuration created at Sun Mar 24 16:17:12 EDT 2013. configure:3949: configure script generated at timestamp 1363707913. configure:3966: checking for basename configure:3984: found /usr/bin/basename configure:3996: result: /usr/bin/basename configure:4025: checking for bash configure:4055: result: /bin/bash configure:4084: checking for cat configure:4102: found /bin/cat configure:4114: result: /bin/cat configure:4143: checking for chmod configure:4161: found /bin/chmod configure:4173: result: /bin/chmod configure:4202: checking for cmp configure:4220: found /usr/bin/cmp configure:4232: result: /usr/bin/cmp configure:4261: checking for comm configure:4279: found /usr/bin/comm configure:4291: result: /usr/bin/comm configure:4320: checking for cp configure:4338: found /bin/cp configure:4350: result: /bin/cp configure:4379: checking for cpio configure:4397: found /usr/bin/cpio configure:4409: result: /usr/bin/cpio configure:4438: checking for cut configure:4456: found /usr/bin/cut configure:4468: result: /usr/bin/cut configure:4497: checking for date configure:4515: found /bin/date configure:4527: result: /bin/date configure:4556: checking for gdiff configure:4589: result: no configure:4556: checking for diff configure:4574: found /usr/bin/diff configure:4586: result: /usr/bin/diff configure:4615: checking for dirname configure:4633: found /usr/bin/dirname configure:4645: result: /usr/bin/dirname configure:4674: checking for echo configure:4692: found /bin/echo configure:4704: result: /bin/echo configure:4733: checking for expr configure:4751: found /bin/expr configure:4763: result: /bin/expr configure:4792: checking for file configure:4810: found /usr/bin/file configure:4822: result: /usr/bin/file configure:4851: checking for find configure:4869: found /usr/bin/find configure:4881: result: /usr/bin/find configure:4910: checking for head configure:4928: found /usr/bin/head configure:4940: result: /usr/bin/head configure:4969: checking for ln configure:4987: found /bin/ln configure:4999: result: /bin/ln configure:5028: checking for ls configure:5046: found /bin/ls configure:5058: result: /bin/ls configure:5087: checking for mkdir configure:5105: found /bin/mkdir configure:5117: result: /bin/mkdir configure:5146: checking for mktemp configure:5164: found /usr/bin/mktemp configure:5176: result: /usr/bin/mktemp configure:5205: checking for mv configure:5223: found /bin/mv configure:5235: result: /bin/mv configure:5264: checking for printf configure:5282: found /usr/bin/printf configure:5294: result: /usr/bin/printf configure:5323: checking for pwd configure:5341: found /bin/pwd configure:5353: result: /bin/pwd configure:5382: checking for rm configure:5400: found /bin/rm configure:5412: result: /bin/rm configure:5441: checking for sh configure:5459: found /bin/sh configure:5471: result: /bin/sh configure:5500: checking for sort configure:5518: found /usr/bin/sort configure:5530: result: /usr/bin/sort configure:5559: checking for tail configure:5577: found /usr/bin/tail configure:5589: result: /usr/bin/tail configure:5618: checking for tar configure:5636: found /usr/bin/tar configure:5648: result: /usr/bin/tar configure:5677: checking for tee configure:5695: found /usr/bin/tee configure:5707: result: /usr/bin/tee configure:5736: checking for touch configure:5754: found /usr/bin/touch configure:5766: result: /usr/bin/touch configure:5795: checking for tr configure:5813: found /usr/bin/tr configure:5825: result: /usr/bin/tr configure:5854: checking for uname configure:5872: found /usr/bin/uname configure:5884: result: /usr/bin/uname configure:5913: checking for uniq configure:5931: found /usr/bin/uniq configure:5943: result: /usr/bin/uniq configure:5972: checking for wc configure:5990: found /usr/bin/wc configure:6002: result: /usr/bin/wc configure:6031: checking for which configure:6049: found /usr/bin/which configure:6061: result: /usr/bin/which configure:6090: checking for xargs configure:6108: found /usr/bin/xargs configure:6120: result: /usr/bin/xargs configure:6150: checking for gawk configure:6180: result: no configure:6150: checking for mawk configure:6180: result: no configure:6150: checking for nawk configure:6180: result: no configure:6150: checking for awk configure:6166: found /usr/bin/awk configure:6177: result: awk configure:6200: checking for grep that handles long lines and -e configure:6258: result: /usr/bin/grep configure:6275: checking for egrep configure:6337: result: /usr/bin/grep -E configure:6354: checking for fgrep configure:6416: result: /usr/bin/grep -F configure:6433: checking for a sed that does not truncate output configure:6497: result: /usr/bin/sed configure:6519: checking for nawk configure:6552: result: no configure:6519: checking for gawk configure:6552: result: no configure:6519: checking for awk configure:6537: found /usr/bin/awk configure:6549: result: /usr/bin/awk configure:6579: checking for cygpath configure:6612: result: no configure:6619: checking for readlink configure:6637: found /usr/bin/readlink configure:6649: result: /usr/bin/readlink configure:6659: checking for df configure:6677: found /bin/df configure:6689: result: /bin/df configure:6699: checking for SetFile configure:6717: found /usr/bin/SetFile configure:6729: result: /usr/bin/SetFile configure:6745: checking build system type configure:6759: result: x86_64-apple-darwin11.4.2 configure:6779: checking host system type configure:6792: result: x86_64-apple-darwin11.4.2 configure:6812: checking target system type configure:6825: result: x86_64-apple-darwin11.4.2 configure:6974: checking openjdk-build os-cpu configure:6976: result: macosx-x86_64 configure:7082: checking openjdk-target os-cpu configure:7084: result: macosx-x86_64 configure:7134: checking compilation type configure:7136: result: native configure:7730: checking for presence of closed sources configure:7737: result: yes configure:7740: checking if closed source is suppressed (openjdk-only) configure:7743: result: no configure:7780: checking which variant of the JDK to build configure:7811: result: normal configure:7827: checking which variants of the JVM to build configure:7846: result: server configure:7905: checking which debug level to use configure:7929: result: release configure:8385: checking what configuration name to use configure:8387: result: macosx-x86_64-normal-server-release configure:8551: checking for apt-get configure:8581: result: no configure:8551: checking for yum configure:8581: result: no configure:8551: checking for port configure:8581: result: no configure:8551: checking for pkgutil configure:8567: found /usr/sbin/pkgutil configure:8578: result: pkgutil configure:8916: checking for gmake configure:8949: result: no configure:9270: checking for make configure:9288: found /usr/bin/make configure:9300: result: /usr/bin/make configure:9315: Testing potential make at /usr/bin/make, found using make in PATH configure:9583: Resolving FOUND_MAKE (as /usr/bin/make) failed, using /usr/bin/make directly. configure:10342: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU Make 3.81) configure:10348: checking if find supports -delete configure:10364: result: yes configure:10378: checking for unzip configure:10396: found /usr/bin/unzip configure:10408: result: /usr/bin/unzip configure:10437: checking for zip configure:10455: found /usr/bin/zip configure:10467: result: /usr/bin/zip configure:10496: checking for ldd configure:10529: result: no configure:10542: checking for otool configure:10560: found /usr/bin/otool configure:10572: result: /usr/bin/otool configure:10587: checking for readelf configure:10620: result: no configure:10587: checking for greadelf configure:10620: result: no configure:10630: checking for hg configure:10648: found /usr/local/bin/hg configure:10660: result: /usr/local/bin/hg configure:10670: checking for stat configure:10688: found /usr/bin/stat configure:10700: result: /usr/bin/stat configure:10710: checking for time configure:10728: found /usr/bin/time configure:10740: result: /usr/bin/time configure:10862: checking for pkg-config configure:10895: result: no configure:11035: checking for 7z configure:11065: result: no configure:11035: checking for unzip configure:11051: found /usr/bin/unzip configure:11062: result: unzip configure:11081: checking for wget configure:11111: result: no configure:11081: checking for lftp configure:11111: result: no configure:11081: checking for ftp configure:11097: found /usr/bin/ftp configure:11108: result: ftp configure:11135: checking headful support configure:11159: result: inlude support for both headful and headless configure:12170: Found potential Boot JDK using /usr/libexec/java_home configure:12330: checking for Boot JDK configure:12332: result: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home configure:12334: checking Boot JDK version configure:12337: result: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b81) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b22, mixed mode) configure:15903: checking for java in Boot JDK configure:15913: result: ok configure:15917: checking for javac in Boot JDK configure:15927: result: ok configure:15931: checking for javah in Boot JDK configure:15941: result: ok configure:15945: checking for javap in Boot JDK configure:15955: result: ok configure:15959: checking for jar in Boot JDK configure:15969: result: ok configure:15973: checking for rmic in Boot JDK configure:15983: result: ok configure:15987: checking for native2ascii in Boot JDK configure:15997: result: ok configure:19071: checking for gcc configure:19089: found /usr/bin/gcc configure:19101: result: /usr/bin/gcc configure:19379: Resolving CC (as /usr/bin/gcc) failed, using /usr/bin/gcc directly. configure:19409: checking resolved symbolic links for CC configure:19460: result: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 configure:19462: checking if CC is disguised ccache configure:19901: result: no, keeping CC configure:19963: Using i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) C compiler version 2336.11.00) (located at /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2) configure:20080: checking for C compiler version configure:20089: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 --version >&5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:20100: $? = 0 configure:20089: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -v >&5 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) configure:20100: $? = 0 configure:20089: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -V >&5 llvm-gcc-4.2: argument to `-V' is missing configure:20100: $? = 1 configure:20089: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -qversion >&5 i686-apple-darwin11-llvm-gcc-4.2: no input files configure:20100: $? = 1 configure:20120: checking whether the C compiler works configure:20142: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 conftest.c >&5 configure:20146: $? = 0 configure:20194: result: yes configure:20197: checking for C compiler default output file name configure:20199: result: a.out configure:20205: checking for suffix of executables configure:20212: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -o conftest conftest.c >&5 configure:20216: $? = 0 configure:20238: result: configure:20260: checking whether we are cross compiling configure:20268: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -o conftest conftest.c >&5 configure:20272: $? = 0 configure:20279: ./conftest configure:20283: $? = 0 configure:20298: result: no configure:20303: checking for suffix of object files configure:20325: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c conftest.c >&5 configure:20329: $? = 0 configure:20350: result: o configure:20354: checking whether we are using the GNU C compiler configure:20373: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c conftest.c >&5 configure:20373: $? = 0 configure:20382: result: yes configure:20391: checking whether /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 accepts -g configure:20411: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c -g conftest.c >&5 configure:20411: $? = 0 configure:20452: result: yes configure:20469: checking for /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 option to accept ISO C89 configure:20533: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c -g -O2 conftest.c >&5 configure:20533: $? = 0 configure:20546: result: none needed configure:20644: checking for g++ configure:20662: found /usr/bin/g++ configure:20674: result: /usr/bin/g++ configure:20952: Resolving CXX (as /usr/bin/g++) failed, using /usr/bin/g++ directly. configure:20982: checking resolved symbolic links for CXX configure:21033: result: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 configure:21035: checking if CXX is disguised ccache configure:21474: result: no, keeping CXX configure:21536: Using i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) C++ compiler version 2336.11.00) (located at /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) configure:21653: checking for C++ compiler version configure:21662: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 --version >&5 i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:21673: $? = 0 configure:21662: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -v >&5 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) configure:21673: $? = 0 configure:21662: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -V >&5 llvm-g++-4.2: argument to `-V' is missing configure:21673: $? = 1 configure:21662: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -qversion >&5 i686-apple-darwin11-llvm-g++-4.2: no input files configure:21673: $? = 1 configure:21677: checking whether we are using the GNU C++ compiler configure:21696: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:21696: $? = 0 configure:21705: result: yes configure:21714: checking whether /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 accepts -g configure:21734: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c -g conftest.cpp >&5 configure:21734: $? = 0 configure:21775: result: yes configure:21856: checking for gcc configure:21872: found /usr/bin/gcc configure:21883: result: gcc configure:21908: checking for Objective C compiler version configure:21917: gcc --version >&5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:21928: $? = 0 configure:21917: gcc -v >&5 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) configure:21928: $? = 0 configure:21917: gcc -V >&5 llvm-gcc-4.2: argument to `-V' is missing configure:21928: $? = 1 configure:21917: gcc -qversion >&5 i686-apple-darwin11-llvm-gcc-4.2: no input files configure:21928: $? = 1 configure:21932: checking whether we are using the GNU Objective C compiler configure:21951: gcc -c conftest.m >&5 configure:21951: $? = 0 configure:21960: result: yes configure:21969: checking whether gcc accepts -g configure:21989: gcc -c -g conftest.m >&5 configure:21989: $? = 0 configure:22030: result: yes configure:22315: Rewriting OBJC to "/usr/bin/gcc" configure:22385: checking for ar configure:22401: found /usr/bin/ar configure:22412: result: ar configure:22696: Rewriting AR to "/usr/bin/ar" configure:24398: checking how to run the C preprocessor configure:24429: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E conftest.c configure:24429: $? = 0 configure:24443: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E conftest.c conftest.c:9:28: error: ac_nonexistent.h: No such file or directory configure:24443: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | #include configure:24468: result: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E configure:24488: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E conftest.c configure:24488: $? = 0 configure:24502: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E conftest.c conftest.c:9:28: error: ac_nonexistent.h: No such file or directory configure:24502: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | #include configure:24766: Resolving CPP (as /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2) failed, using /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 directly. configure:24802: checking how to run the C++ preprocessor configure:24829: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:24829: $? = 0 configure:24843: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp conftest.cpp:9:28: error: ac_nonexistent.h: No such file or directory configure:24843: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | #include configure:24868: result: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E configure:24888: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:24888: $? = 0 configure:24902: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp conftest.cpp:9:28: error: ac_nonexistent.h: No such file or directory configure:24902: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | #include configure:25166: Resolving CXXCPP (as /usr/llvm-gcc-4.2/bin/llvm-g++-4.2) failed, using /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 directly. configure:26498: checking for nm configure:26514: found /usr/bin/nm configure:26525: result: nm configure:26809: Rewriting NM to "/usr/bin/nm" configure:26856: checking for strip configure:26872: found /usr/bin/strip configure:26883: result: strip configure:27167: Rewriting STRIP to "/usr/bin/strip" configure:27596: checking for gobjdump configure:27626: result: no configure:27596: checking for objdump configure:27626: result: no configure:27920: checking for lipo configure:27938: found /usr/bin/lipo configure:27950: result: /usr/bin/lipo configure:28194: Resolving LIPO (as /usr/bin/lipo) failed, using /usr/bin/lipo directly. configure:28235: checking for ANSI C header files configure:28255: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28255: $? = 0 configure:28328: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:28328: $? = 0 configure:28328: ./conftest configure:28328: $? = 0 configure:28339: result: yes configure:28352: checking for sys/types.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for sys/stat.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for stdlib.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for string.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for memory.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for strings.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for inttypes.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for stdint.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28352: checking for unistd.h configure:28352: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28352: $? = 0 configure:28352: result: yes configure:28412: checking stdio.h usability configure:28412: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28412: $? = 0 configure:28412: result: yes configure:28412: checking stdio.h presence configure:28412: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:28412: $? = 0 configure:28412: result: yes configure:28412: checking for stdio.h configure:28412: result: yes configure:28440: checking size of int * configure:28445: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:28445: $? = 0 configure:28445: ./conftest configure:28445: $? = 0 configure:28459: result: 8 configure:28487: checking for target address size configure:28489: result: 64 bits configure:28497: checking whether byte ordering is bigendian configure:28512: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28512: $? = 0 configure:28557: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:28557: $? = 0 configure:28575: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:28: error: 'big' was not declared in this scope conftest.cpp:28: error: expected `;' before 'endian' configure:28575: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STDIO_H 1 | #define SIZEOF_INT_P 8 | /* end confdefs.h. */ | #include | #include | | int | main () | { | #if BYTE_ORDER != BIG_ENDIAN | not big endian | #endif | | ; | return 0; | } configure:28703: result: no configure:29307: checking if we should generate debug symbols configure:29332: result: false configure:29344: checking if we should zip debug-info files configure:29346: result: configure:29402: checking what is not needed on MacOSX? configure:29410: result: alsa pulse x11 configure:29444: checking for explicit Java runtime support in the OS configure:29453: result: yes, but explicitly disabled. configure:29462: checking what is not needed on an X11 build on MacOSX? configure:29466: result: alsa pulse configure:29495: checking for X configure:29603: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:29603: $? = 0 configure:29634: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp -lX11 >&5 ld: library not found for -lX11 collect2: ld returned 1 exit status configure:29634: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STDIO_H 1 | #define SIZEOF_INT_P 8 | /* end confdefs.h. */ | #include | int | main () | { | XrmInitialize () | ; | return 0; | } configure:29684: result: libraries /usr/X11/lib, headers configure:29704: checking whether -R must be followed by a space configure:29720: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp -R/usr/X11/lib >&5 configure:29720: $? = 0 configure:29721: result: no configure:29783: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp -L/usr/X11/lib -R/usr/X11/lib -lX11 >&5 configure:29783: $? = 0 configure:29881: checking for gethostbyname configure:29881: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:29881: $? = 0 configure:29881: result: yes configure:29978: checking for connect configure:29978: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:29978: $? = 0 configure:29978: result: yes configure:30027: checking for remove configure:30027: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:30027: $? = 0 configure:30027: result: yes configure:30076: checking for shmat configure:30076: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest conftest.cpp >&5 configure:30076: $? = 0 configure:30076: result: yes configure:30134: checking for IceConnectionNumber in -lICE configure:30159: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -L/usr/X11/lib conftest.cpp -lICE >&5 configure:30159: $? = 0 configure:30168: result: yes configure:30255: checking for X11/extensions/shape.h configure:30255: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c conftest.c >&5 configure:30255: $? = 0 configure:30255: result: yes configure:30255: checking for X11/extensions/Xrender.h configure:30255: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c conftest.c >&5 configure:30255: $? = 0 configure:30255: result: yes configure:30255: checking for X11/extensions/XTest.h configure:30255: /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c conftest.c >&5 configure:30255: $? = 0 configure:30255: result: yes configure:30501: checking cups/cups.h usability configure:30501: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:30501: $? = 0 configure:30501: result: yes configure:30501: checking cups/cups.h presence configure:30501: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:30501: $? = 0 configure:30501: result: yes configure:30501: checking for cups/cups.h configure:30501: result: yes configure:30501: checking cups/ppd.h usability configure:30501: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c conftest.cpp >&5 configure:30501: $? = 0 configure:30501: result: yes configure:30501: checking cups/ppd.h presence configure:30501: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E conftest.cpp configure:30501: $? = 0 configure:30501: result: yes configure:30501: checking for cups/ppd.h configure:30501: result: yes configure:31031: checking for FREETYPE2 configure:31105: checking for freetype in some standard locations configure:31128: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include -L/usr/X11/lib -lfreetype conftest.cpp >&5 configure:31128: $? = 0 configure:31144: result: yes configure:31181: checking for FT_Init_FreeType in -lfreetype configure:31206: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include -L/usr/X11/lib -lfreetype conftest.cpp -lfreetype >&5 configure:31206: $? = 0 configure:31215: result: yes configure:31562: checking for main in -ljpeg configure:31581: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp -ljpeg >&5 ld: library not found for -ljpeg collect2: ld returned 1 exit status configure:31581: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STDIO_H 1 | #define SIZEOF_INT_P 8 | #define HAVE_X11_EXTENSIONS_SHAPE_H 1 | #define HAVE_X11_EXTENSIONS_XRENDER_H 1 | #define HAVE_X11_EXTENSIONS_XTEST_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CUPS_PPD_H 1 | /* end confdefs.h. */ | | | int | main () | { | return main (); | ; | return 0; | } configure:31590: result: no configure:31601: Will use jpeg decoder bundled with the OpenJDK source configure:31614: checking for main in -lgif configure:31633: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp -lgif >&5 ld: library not found for -lgif collect2: ld returned 1 exit status configure:31633: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STDIO_H 1 | #define SIZEOF_INT_P 8 | #define HAVE_X11_EXTENSIONS_SHAPE_H 1 | #define HAVE_X11_EXTENSIONS_XRENDER_H 1 | #define HAVE_X11_EXTENSIONS_XTEST_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CUPS_PPD_H 1 | /* end confdefs.h. */ | | | int | main () | { | return main (); | ; | return 0; | } configure:31642: result: no configure:31653: Will use gif decoder bundled with the OpenJDK source configure:31672: checking for compress in -lz configure:31697: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp -lz >&5 configure:31697: $? = 0 configure:31706: result: yes configure:31715: checking for which zlib to use configure:31747: result: system configure:31781: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:30: error: 'altzone' was not declared in this scope configure:31781: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STDIO_H 1 | #define SIZEOF_INT_P 8 | #define HAVE_X11_EXTENSIONS_SHAPE_H 1 | #define HAVE_X11_EXTENSIONS_XRENDER_H 1 | #define HAVE_X11_EXTENSIONS_XTEST_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CUPS_PPD_H 1 | /* end confdefs.h. */ | #include | int | main () | { | return (int)altzone; | ; | return 0; | } configure:31799: checking for cos in -lm configure:31824: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp -lm >&5 configure:31824: $? = 0 configure:31833: result: yes configure:31857: checking for dlopen in -ldl configure:31882: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp -ldl >&5 configure:31882: $? = 0 configure:31891: result: yes configure:32136: checking if elliptic curve crypto implementation is present configure:32141: result: yes configure:32170: checking for number of cores configure:32194: result: 2 configure:32220: checking for memory size configure:32248: result: 4096 MB configure:32273: checking for appropriate number of jobs to run in parallel configure:32291: result: 2 configure:32505: checking whether to use sjavac configure:32514: result: no configure:32550: checking that precompiled headers work configure:32559: result: yes configure:32581: checking for ccache configure:32599: found /usr/local/bin/ccache configure:32611: result: /usr/local/bin/ccache configure:32647: checking if ccache supports precompiled headers configure:32655: result: yes configure:32657: checking if C-compiler supports ccache precompiled headers configure:32672: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -c -fpch-preprocess -I/usr/X11/include/freetype2 -I/usr/X11/include conftest.cpp >&5 configure:32672: $? = 0 configure:32680: result: yes configure:32721: checking if build directory is on local disk configure:32747: result: yes configure:32781: checking Checking for deploy src configure:32784: result: found configure:32796: checking Checking for install src configure:32799: result: found configure:32830: checking for ant configure:32848: found /usr/bin/ant configure:32860: result: /usr/bin/ant configure:32895: WARNING: Junit could not be found. Needed for deploy repo. configure:32936: WARNING: Mozilla headers could not be found. Disabling deploy build. configure:34949: WARNING: JAVAFX cobundle could not be found. Disabling installer build. configure:35134: checking for jdk debug image dir configure:35390: result: Not found configure:35475: checking whether to build JFR configure:35487: result: yes (default) configure:35523: checking whether to build commercial features configure:35536: result: yes (default) configure:35689: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by OpenJDK config.status jdk8, which was generated by GNU Autoconf 2.67. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/config.status on sharks config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/hotspot-spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/bootcycle-spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/compare.sh config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/spec.sh config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/Makefile config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/custom-spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/deploy-spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/install-spec.gmk config.status:1194: creating /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/config.h config.status:1348: /Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/config.h is unchanged ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-apple-darwin11.4.2 ac_cv_c_bigendian=no ac_cv_c_compiler_gnu=yes ac_cv_cxx_compiler_gnu=yes ac_cv_env_ALSA_CFLAGS_set= ac_cv_env_ALSA_CFLAGS_value= ac_cv_env_ALSA_LIBS_set= ac_cv_env_ALSA_LIBS_value= ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_FREETYPE2_CFLAGS_set= ac_cv_env_FREETYPE2_CFLAGS_value= ac_cv_env_FREETYPE2_LIBS_set= ac_cv_env_FREETYPE2_LIBS_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_OBJCFLAGS_set= ac_cv_env_OBJCFLAGS_value= ac_cv_env_OBJC_set= ac_cv_env_OBJC_value= ac_cv_env_PKG_CONFIG_set= ac_cv_env_PKG_CONFIG_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_func_connect=yes ac_cv_func_gethostbyname=yes ac_cv_func_remove=yes ac_cv_func_shmat=yes ac_cv_have_x='have_x=yes ac_x_includes='\'''\'' ac_x_libraries='\''/usr/X11/lib'\''' ac_cv_header_X11_extensions_XTest_h=yes ac_cv_header_X11_extensions_Xrender_h=yes ac_cv_header_X11_extensions_shape_h=yes ac_cv_header_cups_cups_h=yes ac_cv_header_cups_ppd_h=yes ac_cv_header_inttypes_h=yes ac_cv_header_memory_h=yes ac_cv_header_stdc=yes ac_cv_header_stdint_h=yes ac_cv_header_stdio_h=yes ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_host=x86_64-apple-darwin11.4.2 ac_cv_lib_ICE_IceConnectionNumber=yes ac_cv_lib_dl_dlopen=yes ac_cv_lib_freetype_FT_Init_FreeType=yes ac_cv_lib_gif_main=no ac_cv_lib_jpeg_main=no ac_cv_lib_m_cos=yes ac_cv_lib_z_compress=yes ac_cv_objc_compiler_gnu=yes ac_cv_objext=o ac_cv_path_ANT_EXE=/usr/bin/ant ac_cv_path_BASENAME=/usr/bin/basename ac_cv_path_BASH=/bin/bash ac_cv_path_CAT=/bin/cat ac_cv_path_CCACHE=/usr/local/bin/ccache ac_cv_path_CHECK_MAKE=/usr/bin/make ac_cv_path_CHMOD=/bin/chmod ac_cv_path_CMP=/usr/bin/cmp ac_cv_path_COMM=/usr/bin/comm ac_cv_path_CP=/bin/cp ac_cv_path_CPIO=/usr/bin/cpio ac_cv_path_CUT=/usr/bin/cut ac_cv_path_DATE=/bin/date ac_cv_path_DF=/bin/df ac_cv_path_DIFF=/usr/bin/diff ac_cv_path_DIRNAME=/usr/bin/dirname ac_cv_path_ECHO=/bin/echo ac_cv_path_EGREP='/usr/bin/grep -E' ac_cv_path_EXPR=/bin/expr ac_cv_path_FGREP='/usr/bin/grep -F' ac_cv_path_FILE=/usr/bin/file ac_cv_path_FIND=/usr/bin/find ac_cv_path_GREP=/usr/bin/grep ac_cv_path_HEAD=/usr/bin/head ac_cv_path_HG=/usr/local/bin/hg ac_cv_path_LIPO=/usr/bin/lipo ac_cv_path_LN=/bin/ln ac_cv_path_LS=/bin/ls ac_cv_path_MKDIR=/bin/mkdir ac_cv_path_MKTEMP=/usr/bin/mktemp ac_cv_path_MV=/bin/mv ac_cv_path_NAWK=/usr/bin/awk ac_cv_path_OTOOL=/usr/bin/otool ac_cv_path_POTENTIAL_CC=/usr/bin/gcc ac_cv_path_POTENTIAL_CXX=/usr/bin/g++ ac_cv_path_PRINTF=/usr/bin/printf ac_cv_path_READLINK=/usr/bin/readlink ac_cv_path_RM=/bin/rm ac_cv_path_SED=/usr/bin/sed ac_cv_path_SETFILE=/usr/bin/SetFile ac_cv_path_SH=/bin/sh ac_cv_path_SORT=/usr/bin/sort ac_cv_path_STAT=/usr/bin/stat ac_cv_path_TAIL=/usr/bin/tail ac_cv_path_TAR=/usr/bin/tar ac_cv_path_TEE=/usr/bin/tee ac_cv_path_THEPWDCMD=/bin/pwd ac_cv_path_TIME=/usr/bin/time ac_cv_path_TOUCH=/usr/bin/touch ac_cv_path_TR=/usr/bin/tr ac_cv_path_UNAME=/usr/bin/uname ac_cv_path_UNIQ=/usr/bin/uniq ac_cv_path_UNZIP=/usr/bin/unzip ac_cv_path_WC=/usr/bin/wc ac_cv_path_WHICH=/usr/bin/which ac_cv_path_XARGS=/usr/bin/xargs ac_cv_path_ZIP=/usr/bin/zip ac_cv_prog_AWK=awk ac_cv_prog_BDEPS_FTP=ftp ac_cv_prog_BDEPS_UNZIP=unzip ac_cv_prog_CPP='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E' ac_cv_prog_CXXCPP='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E' ac_cv_prog_PKGHANDLER=pkgutil ac_cv_prog_ac_ct_AR=ar ac_cv_prog_ac_ct_NM=nm ac_cv_prog_ac_ct_OBJC=gcc ac_cv_prog_ac_ct_STRIP=strip ac_cv_prog_cc_c89= ac_cv_prog_cc_g=yes ac_cv_prog_cxx_g=yes ac_cv_prog_objc_g=yes ac_cv_sizeof_int_p=8 ac_cv_target=x86_64-apple-darwin11.4.2 ## ----------------- ## ## Output variables. ## ## ----------------- ## ADD_SRC_ROOT='' ALSA_CFLAGS='' ALSA_LIBS='' ANT='/usr/bin/ant' ANT_EXE='/usr/bin/ant' ANT_HOME='' AR='/usr/bin/ar' ARFLAGS='-r' AR_OUT_OPTION='rcs$(SPACE)' AS='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c' AWK='awk' BASENAME='/usr/bin/basename' BASE_IMAGE_DIR='' BASH='/bin/bash' BDEPS_FTP='ftp' BDEPS_UNZIP='unzip' BOOT_JDK='/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home' BOOT_JDK_JVMARGS=' -Xms64M -Xmx1600M -XX:ThreadStackSize=1536' BOOT_JDK_SOURCETARGET='-source 7 -target 7' BOOT_RTJAR='/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/rt.jar' BOOT_TOOLSJAR='/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/lib/tools.jar' BUILD_CC='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' BUILD_CXX='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2' BUILD_DEPLOY='false' BUILD_HEADLESS='BUILD_HEADLESS:=true' BUILD_HEADLESS_ONLY='' BUILD_HOTSPOT='true' BUILD_INSTALL='false' BUILD_LD='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' BUILD_LOG='$(OUTPUT_ROOT)/build.log' BUILD_LOG_PREVIOUS='$(OUTPUT_ROOT)/build.log.old' BUILD_LOG_WRAPPER='$(BASH) $(SRC_ROOT)/common/bin/logger.sh $(BUILD_LOG)' BUILD_OUTPUT='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release' BUILD_VARIANT_RELEASE='' BUNDLE_DATE='24_mar_2013' CACERTS_FILE='/Users/aherrick/jdk8.april/jdk/src/closed/share/lib/security/cacerts.internal' CAT='/bin/cat' CC='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' CCACHE='CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache' CCSS_SIGNING_DIR='' CC_OUT_OPTION='-o$(SPACE)' CFLAGS='' CFLAGS_DEBUG_SYMBOLS='' CFLAGS_JDKEXE=' -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DMACOSX -D_ALLBSD_SOURCE -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) -mmacosx-version-min=$(MACOSX_VERSION_MIN) -DNDEBUG -DARCH='\''"x86_64"'\'' -Dx86_64 -DRELEASE='\''""'\'' -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include/macosx -I/Users/aherrick/jdk8.april/jdk/src/share/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/solaris/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/share/native/common -I/Users/aherrick/jdk8.april/jdk/src/solaris/native/common -fno-strict-aliasing' CFLAGS_JDKLIB=' -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DMACOSX -D_ALLBSD_SOURCE -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) -mmacosx-version-min=$(MACOSX_VERSION_MIN) -DNDEBUG -DARCH='\''"x86_64"'\'' -Dx86_64 -DRELEASE='\''""'\'' -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include/macosx -I/Users/aherrick/jdk8.april/jdk/src/share/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/solaris/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/share/native/common -I/Users/aherrick/jdk8.april/jdk/src/solaris/native/common -fno-strict-aliasing -fPIC ' CHECK_GMAKE='' CHECK_MAKE='/usr/bin/make' CHECK_TOOLSDIR_GMAKE='' CHECK_TOOLSDIR_MAKE='' CHMOD='/bin/chmod' CMP='/usr/bin/cmp' COMM='/usr/bin/comm' COMPANY_NAME='Oracle Corporation' COMPILER_PATH='' COMPILER_TYPE='CC' COMPILE_TYPE='native' COMPRESS_JARS='false' CONFIGURE_COMMAND_LINE='--with-junit-dir=/Users/aherrick/java/devtools/share/junit/latest --with-devtools-path=/Users/aherrick/java/devtools --with-mozilla-headers=/Users/aherrick/java/devtools/share/plugin --with-sparkle-framework=/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6 --with-javafx-zip-dir=' CONF_NAME='macosx-x86_64-normal-server-release' COOKED_BUILD_NUMBER='0' COPYRIGHT_YEAR='2013' CORBA_TOPDIR='/Users/aherrick/jdk8.april/corba' CP='/bin/cp' CPIO='/usr/bin/cpio' CPP='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -E' CPPFLAGS='' CSCRIPT='' CUPS_CFLAGS='' CUSTOM_MAKE_DIR='/Users/aherrick/jdk8.april/common/autoconf/../../jdk/make/closed/autoconf//../' CUT='/usr/bin/cut' CXX='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2' CXXCPP='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -E' CXXFLAGS=' -I/usr/X11/include/freetype2 -I/usr/X11/include' CXXFLAGS_DEBUG_SYMBOLS='' CXXFLAGS_JDKEXE=' -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DMACOSX -D_ALLBSD_SOURCE -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) -mmacosx-version-min=$(MACOSX_VERSION_MIN) -DNDEBUG -DARCH='\''"x86_64"'\'' -Dx86_64 -DRELEASE='\''""'\'' -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include/macosx -I/Users/aherrick/jdk8.april/jdk/src/share/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/solaris/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/share/native/common -I/Users/aherrick/jdk8.april/jdk/src/solaris/native/common ' CXXFLAGS_JDKLIB=' -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DMACOSX -D_ALLBSD_SOURCE -DMAC_OS_X_VERSION_MAX_ALLOWED=$(subst .,,$(MACOSX_VERSION_MIN)) -mmacosx-version-min=$(MACOSX_VERSION_MIN) -DNDEBUG -DARCH='\''"x86_64"'\'' -Dx86_64 -DRELEASE='\''""'\'' -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include -I/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/include/macosx -I/Users/aherrick/jdk8.april/jdk/src/share/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/solaris/javavm/export -I/Users/aherrick/jdk8.april/jdk/src/share/native/common -I/Users/aherrick/jdk8.april/jdk/src/solaris/native/common -fPIC ' CXX_FLAG_DEPS='-MMD -MF' CXX_FLAG_REORDER='' CXX_O_FLAG_HI='-Os' CXX_O_FLAG_HIGHEST='-Os' CXX_O_FLAG_NONE='' CXX_O_FLAG_NORM='-Os' CYGPATH='' CYGWIN_LINK='' C_FLAG_DEPS='-MMD -MF' C_FLAG_REORDER='' C_O_FLAG_HI='-Os' C_O_FLAG_HIGHEST='-Os' C_O_FLAG_NONE='' C_O_FLAG_NORM='-Os' DATE='/bin/date' DATE_WHEN_CONFIGURED='Sun Mar 24 16:17:12 EDT 2013' DEBUG_CLASSFILES='false' DEBUG_LEVEL='release' DEFINE_CROSS_COMPILE_ARCH='' DEFS='-DHAVE_CONFIG_H' DEPLOY_SPEC='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/deploy-spec.gmk' DEPLOY_TOPDIR='/Users/aherrick/jdk8.april/deploy' DEVTOOLS_PATH='' DF='/bin/df' DIFF='/usr/bin/diff' DIRNAME='/usr/bin/dirname' DISABLE_COMMERCIAL_FEATURES='false' DUMPBIN='' DXSDK_INCLUDE_PATH='' DXSDK_LIB_PATH='' ECHO='/bin/echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='/usr/bin/grep -E' ENABLE_DEBUG_SYMBOLS='false' ENABLE_INTREE_EC='yes' ENABLE_JFR='true' ENABLE_SJAVAC='no' EXEEXT='' EXE_OUT_OPTION='-o$(SPACE)' EXE_SUFFIX='' EXPR='/bin/expr' EXT_LIBS_PATH='' FASTDEBUG='false' FGREP='/usr/bin/grep -F' FILE='/usr/bin/file' FIND='/usr/bin/find' FIND_DELETE='-delete' FIXPATH='' FREETYPE2_CFLAGS='-I/usr/X11/include/freetype2 -I/usr/X11/include' FREETYPE2_LIBS='-L/usr/X11/lib -lfreetype' FREETYPE2_LIB_PATH='' GCC29_COMPILER_KIT='' GREP='/usr/bin/grep' HEAD='/usr/bin/head' HG='/usr/local/bin/hg' HOTSPOT_CXX='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2' HOTSPOT_DIST='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/hotspot/dist' HOTSPOT_LD='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' HOTSPOT_MAKE_ARGS='universal_product' HOTSPOT_MT='' HOTSPOT_RC='' HOTSPOT_TOPDIR='/Users/aherrick/jdk8.april/hotspot' INSTALL_SPEC='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/install-spec.gmk' INSTALL_TOPDIR='/Users/aherrick/jdk8.april/install' JAVAC_CHECK='' JAVAC_FLAGS='' JAVAFX_ZIP_DIR='' JAVASE_EMBEDDED='' JAVA_CHECK='' JAXP_TOPDIR='/Users/aherrick/jdk8.april/jaxp' JAXWS_TOPDIR='/Users/aherrick/jdk8.april/jaxws' JDK_BUILD_NUMBER='b00' JDK_DEBUG_IMAGE_DIR='' JDK_MAJOR_VERSION='1' JDK_MICRO_VERSION='0' JDK_MINOR_VERSION='8' JDK_MKTG_UNDERSCORE_VERSION='8' JDK_MKTG_VERSION='8' JDK_RC_PLATFORM_NAME='Platform SE' JDK_TOPDIR='/Users/aherrick/jdk8.april/jdk' JDK_UNDERSCORE_VERSION='1_8_0' JDK_UPDATE_VERSION='' JDK_VARIANT='normal' JDK_VERSION='1.8.0' JOBS='2' JUNIT_DIR='/Users/aherrick/java/devtools/share/junit/latest' JVM_VARIANTS=',server,' JVM_VARIANT_CLIENT='false' JVM_VARIANT_KERNEL='false' JVM_VARIANT_MINIMAL1='false' JVM_VARIANT_SERVER='true' JVM_VARIANT_ZERO='false' JVM_VARIANT_ZEROSHARK='false' LANGTOOLS_TOPDIR='/Users/aherrick/jdk8.april/langtools' LAUNCHER_NAME='java' LD='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' LDCXX='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2' LDD='true' LDEXE='/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2' LDEXECXX='/usr/llvm-gcc-4.2/bin/llvm-g++-4.2' LDFLAGS='' LDFLAGS_CXX_JDK='' LDFLAGS_JDKEXE=' -mmacosx-version-min=$(MACOSX_VERSION_MIN)' LDFLAGS_JDKEXE_SUFFIX='' LDFLAGS_JDKLIB=' -mmacosx-version-min=$(MACOSX_VERSION_MIN) -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -fPIC -L/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/lib -L/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/jdk/lib/server' LDFLAGS_JDKLIB_SUFFIX='-ljava -ljvm' LD_OUT_OPTION='-o$(SPACE)' LEGACY_EXTRA_CFLAGS='' LEGACY_EXTRA_CXXFLAGS='' LEGACY_EXTRA_LDFLAGS='' LIBCXX='-lstdc++' LIBDL='-ldl ' LIBM='' LIBOBJS='' LIBRARY_PREFIX='lib' LIBS='-lm ' LIBZIP_CAN_USE_MMAP='true' LIPO='/usr/bin/lipo' LN='/bin/ln' LP64='LP64:=' LS='/bin/ls' LTLIBOBJS='' MACOSX_BUNDLE_ID_BASE='com.oracle.java' MACOSX_BUNDLE_NAME_BASE='Java SE' MACOSX_UNIVERSAL='true' MACOSX_VERSION_MIN='10.7.0' MAKE='/usr/bin/make' MCS='' MEMORY_SIZE='4096' MIDL='' MILESTONE='internal' MINIMIZE_RAM_USAGE='' MKDIR='/bin/mkdir' MKTEMP='/usr/bin/mktemp' MOZILLA_HEADERS='/Users/aherrick/java/devtools/share/plugin' MSICERT='' MSITRAN='' MSVCR_DLL='' MT='' MV='/bin/mv' NASHORN_TOPDIR='/Users/aherrick/jdk8.april/nashorn' NAWK='/usr/bin/awk' NM='/usr/bin/nm' NO_RTPATCH='' NUM_CORES='2' OBJC='/usr/bin/gcc' OBJCFLAGS='' OBJCOPY='' OBJDUMP='' OBJEXT='o' OBJ_SUFFIX='.o' OPENJDK_BUILD_AUTOCONF_NAME='x86_64-apple-darwin11.4.2' OPENJDK_BUILD_CPU='x86_64' OPENJDK_BUILD_CPU_ARCH='x86' OPENJDK_BUILD_CPU_BITS='64' OPENJDK_BUILD_CPU_ENDIAN='little' OPENJDK_BUILD_OS='macosx' OPENJDK_BUILD_OS_API='posix' OPENJDK_TARGET_AUTOCONF_NAME='x86_64-apple-darwin11.4.2' OPENJDK_TARGET_CPU='x86_64' OPENJDK_TARGET_CPU_ARCH='x86' OPENJDK_TARGET_CPU_BITS='64' OPENJDK_TARGET_CPU_ENDIAN='little' OPENJDK_TARGET_CPU_ISADIR='' OPENJDK_TARGET_CPU_JLI_CFLAGS='-DLIBARCHNAME='\''"x86_64"'\''' OPENJDK_TARGET_CPU_LEGACY='x86_64' OPENJDK_TARGET_CPU_LEGACY_LIB='amd64' OPENJDK_TARGET_CPU_LIBDIR='' OPENJDK_TARGET_CPU_OSARCH='x86_64' OPENJDK_TARGET_OS='macosx' OPENJDK_TARGET_OS_API='posix' OPENJDK_TARGET_OS_API_DIR='solaris' OPENWIN_HOME='' OS_VERSION_MAJOR='11' OS_VERSION_MICRO='2' OS_VERSION_MINOR='4' OTOOL='/usr/bin/otool' OUTPUT_ROOT='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release' OVERRIDE_SRC_ROOT='' PACKAGE_BUGREPORT='build-dev at openjdk.java.net' PACKAGE_NAME='OpenJDK' PACKAGE_PATH='/opt/local' PACKAGE_STRING='OpenJDK jdk8' PACKAGE_TARNAME='openjdk' PACKAGE_URL='http://openjdk.java.net' PACKAGE_VERSION='jdk8' PATH_SEP=':' PATH_SEPARATOR=':' PKGHANDLER='pkgutil' PKG_CONFIG='' POST_MCS_CMD='' POST_STRIP_CMD='/usr/bin/strip -S' POTENTIAL_CC='/usr/bin/gcc' POTENTIAL_CXX='/usr/bin/g++' PRINTF='/usr/bin/printf' PRODUCT_NAME='Java(TM)' PRODUCT_SUFFIX='SE Runtime Environment' PROPER_COMPILER_CC='' PROPER_COMPILER_CXX='' RC='' RC_FLAGS='' READELF='' READLINK='' REBASE='' REQUIRED_OS_NAME='Darwin' REQUIRED_OS_VERSION='11.2' RM='/bin/rm -f' RTPATCH_DIR='' SALIB_NAME='libsaproc.dylib' SED='/usr/bin/sed' SETFILE='/usr/bin/SetFile' SET_EXECUTABLE_ORIGIN='-Xlinker -rpath -Xlinker @loader_path/.' SET_OPENJDK='' SET_SHARED_LIBRARY_MAPFILE='' SET_SHARED_LIBRARY_NAME='-Xlinker -install_name -Xlinker @rpath/$1' SET_SHARED_LIBRARY_ORIGIN='-Xlinker -rpath -Xlinker @loader_path/.' SH='/bin/sh' SHARED_LIBRARY='lib$1.dylib' SHARED_LIBRARY_FLAGS='-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -fPIC' SHARED_LIBRARY_SUFFIX='.dylib' SHELL='/bin/sh' SJAVAC_SERVER_CORES='2' SJAVAC_SERVER_DIR='' SJAVAC_SERVER_JAVA='/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -verbosegc -Xms1G -Xmx2500M -XX:ThreadStackSize=1536' SORT='/usr/bin/sort' SPARKLE_FRAMEWORK='/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6' SPEC='/Users/aherrick/jdk8.april/build/macosx-x86_64-normal-server-release/spec.gmk' SRC_ROOT='/Users/aherrick/jdk8.april' STAT='/usr/bin/stat' STATIC_CXX_SETTING='' STATIC_LIBRARY='lib$1.a' STATIC_LIBRARY_SUFFIX='.a' STRIP='/usr/bin/strip' SUPPORT_HEADFUL='yes' SUPPORT_HEADLESS='yes' SYS_ROOT='/' TAIL='/usr/bin/tail' TAR='/usr/bin/tar' TEE='/usr/bin/tee' TEST_IN_BUILD='false' THEPWDCMD='/bin/pwd' TIME='/usr/bin/time' TOOLS_DIR_CC='' TOOLS_DIR_CXX='' TOUCH='/usr/bin/touch' TR='/usr/bin/tr' UNAME='/usr/bin/uname' UNIQ='/usr/bin/uniq' UNLIMITED_CRYPTO='false' UNZIP='/usr/bin/unzip' USER_RELEASE_SUFFIX='aherrick_2013_03_24_16_17' USE_EXTERNAL_LIBGIF='false' USE_EXTERNAL_LIBJPEG='true' USE_EXTERNAL_LIBZ='true' USE_PRECOMPILED_HEADER='1' USING_SYSTEM_FT_LIB='true' VARIANT='OPT' VS_INCLUDE='' VS_LIB='' VS_PATH='' WC='/usr/bin/wc' WHICH='/usr/bin/which' WINAR='' WINLD='' WIXDIR='' WSCRIPT='' XARGS='/usr/bin/xargs' XMKMF='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS=' -L/usr/X11/lib -R/usr/X11/lib' X_PRE_LIBS=' -lSM -lICE' ZIP='/usr/bin/zip' ZIP_DEBUGINFO_FILES='true' ac_ct_CC='' ac_ct_CXX='' ac_ct_OBJC='gcc' ac_ct_OBJCOPY='' ac_ct_OBJDUMP='' ac_ct_PROPER_COMPILER_CC='' ac_ct_PROPER_COMPILER_CXX='' bindir='${exec_prefix}/bin' build='x86_64-apple-darwin11.4.2' build_alias='' build_cpu='x86_64' build_os='darwin11.4.2' build_vendor='apple' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='${prefix}' host='x86_64-apple-darwin11.4.2' host_alias='' host_cpu='x86_64' host_os='darwin11.4.2' host_vendor='apple' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target='x86_64-apple-darwin11.4.2' target_alias='' target_cpu='x86_64' target_os='darwin11.4.2' target_vendor='apple' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "OpenJDK" #define PACKAGE_TARNAME "openjdk" #define PACKAGE_VERSION "jdk8" #define PACKAGE_STRING "OpenJDK jdk8" #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" #define PACKAGE_URL "http://openjdk.java.net" #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_STDIO_H 1 #define SIZEOF_INT_P 8 #define HAVE_X11_EXTENSIONS_SHAPE_H 1 #define HAVE_X11_EXTENSIONS_XRENDER_H 1 #define HAVE_X11_EXTENSIONS_XTEST_H 1 #define HAVE_CUPS_CUPS_H 1 #define HAVE_CUPS_PPD_H 1 #define HAVE_LIBM 1 #define HAVE_LIBDL 1 configure: exit 0 From chris.gruszka at oracle.com Sun Mar 24 18:48:45 2013 From: chris.gruszka at oracle.com (chris gruszka) Date: Sun, 24 Mar 2013 21:48:45 -0400 Subject: Setup JDK Build on Mac with new build infrastructure In-Reply-To: References: Message-ID: <514FACFD.9030305@oracle.com> Andy, Add the --with-mozilla-headers and --with-javafx-zip-dir options to configure. For example: --with-mozilla-headers=/opt/jprt/products/P1/npapi_1.0/plugin --with-javafx-zip-dir=/opt/jprt/products/P1/fxsdk8mac64 -ChrisG On 3/24/2013 8:52 PM, build-infra-dev-request at openjdk.java.net wrote: On 3/24/2013 4:33 PM, Andy Herrick wrote: > OK - Now using the new build infrastructure on MacOSX - and I can > build with no errors, but is not building deploy and install. > I am using configuration generated by: > bash configure > --with-junit-dir=/Users/aherrick/java/devtools/share/junit/latest > --with-devtools-path=/Users/aherrick/java/devtools > --with-mozilla-headers=/Users/aherrick/java/devtools/share/plugin > --with-sparkle-framework=/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6 > --with-javafx-zip-dir= > > the config log is attached. > > It seems to find the closed code and so is not trying to build openJDK > , but it may be building new server jdk. > > anyone know how to build everything ? > > /Andy > configure:32895: WARNING: Junit could not be found. Needed for deploy repo. > configure:32936: WARNING: Mozilla headers could not be found. Disabling deploy build. > configure:34949: WARNING: JAVAFX cobundle could not be found. Disabling installer build. From weijun.wang at oracle.com Mon Mar 25 01:31:46 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Mar 2013 16:31:46 +0800 Subject: Setup JDK Build on Mac with new build infrastructure In-Reply-To: <514F859E.9000901@oracle.com> References: <5149D0AA.1050000@oracle.com> <499E465B-04F7-4746-94F4-5839FD442FBE@oracle.com> <5149D500.8000607@oracle.com> <5149E6B3.9090602@oracle.com> <5149E982.5070602@oracle.com> <514F631E.4020508@oracle.com> <514F859E.9000901@oracle.com> Message-ID: <51500B72.9090404@oracle.com> Line 910 of your config.log still shows configure:32936: WARNING: Mozilla headers could not be found. Disabling deploy build. Do you have plugin2_7_mozilla_headers inside your share/plugin? -Max On 3/25/13 7:00 AM, Andy Herrick wrote: > > On 3/24/2013 4:33 PM, Andy Herrick wrote: >> OK - Now using the new build infrastructure on MacOSX - and I can >> build with no errors, but is not building deploy and install. >> I am using configuration generated by: >> bash configure >> --with-junit-dir=/Users/aherrick/java/devtools/share/junit/latest >> --with-devtools-path=/Users/aherrick/java/devtools >> --with-mozilla-headers=/Users/aherrick/java/devtools/share/plugin >> --with-sparkle-framework=/Users/aherrick/java/devtools/macosx/Sparkle/1.5b6 >> --with-javafx-zip-dir= >> >> the config log is attached. >> >> It seems to find the closed code and so is not trying to build openJDK >> , but it may be building new server jdk. >> >> anyone know how to build everything ? >> >> /Andy >> >> > From jesper.wilhelmsson at oracle.com Mon Mar 25 09:29:20 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 17:29:20 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans Message-ID: <51507B60.6030809@oracle.com> Hi, Sorry for cross posting, but I think this could be useful for several areas. I would like to add Solaris Studio / NetBeans project files for the entire OpenJDK project. To clarify: One project that contains the entire OpenJDK. With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly fast and even though I personally mostly work in the HotSpot tree, I tend to always clone and build the entire JDK forest. I find this to have several benefits. Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ The configuration in this project is currently Mac only. Linux and Solaris configurations are also planned. The webrev is made from the jdk8/build repository which is where I think a change like this should go in. Let me know if you think something else. To use this project (once pushed): 1. Clone your favorite repository hg clone http://hg.openjdk.java.net/hsx/hotspot-gc 2. Get the whole forest cd hotspot-gc sh get_source.sh 3. Configure sh configure 4. Open Solaris studio / NetBeans and load the project. The project in located in the common directory. Thanks, /Jesper From mike.duigou at oracle.com Mon Mar 25 09:51:30 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Mar 2013 09:51:30 -0700 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <4C13F400-6CC9-456D-BFCA-2F7A32C769EC@oracle.com> It's nice to see more work in this area and I was very pleased to see how small the project is. The configurations.xml file with it's long file lists worries me though. Is there any way to generate this information dynamically? I worry that the file lists wills be chronically forgotten and thus inevitably stale. Do you use this project mostly for editing or for building, testing and debugging as well? Mike On Mar 25 2013, at 09:29 , Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several areas. > > I would like to add Solaris Studio / NetBeans project files for the entire OpenJDK project. To clarify: One project that contains the entire OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly fast and even though I personally mostly work in the HotSpot tree, I tend to always clone and build the entire JDK forest. I find this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and Solaris configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think a change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper From dmitry.samersoff at oracle.com Mon Mar 25 10:11:33 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 21:11:33 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <51508545.6040102@oracle.com> Jesper, Tryed to apply your patch as I'm quite inetresting to have really working NB project for jdk and hotspot. 1. Directory structure looks strange (see screenshot1) 2. netbeans doesn't work for JDK tests (see screenshot2) - netbeans doesn't pick files from test directory (JDK-only project have the same issue) netbeans doesn't pick changes from files in JDK tree - i.e if I add/change class name in JDK tree, netbeans still treated it as unresolved within test (JDK-only project have the same issue) -Dmitry On 2013-03-25 20:29, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several > areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK > is fairly fast and even though I personally mostly work in the HotSpot > tree, I tend to always clone and build the entire JDK forest. I find > this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and > Solaris configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think > a change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Mon Mar 25 10:11:54 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 21:11:54 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <5150855A.9020909@oracle.com> Jesper, Tried to apply your patch as I'm quite interesting to have really working NB project for jdk and hotspot. 1. Directory structure looks strange (see screenshot1) 2. netbeans doesn't work for JDK tests (see screenshot2) - netbeans doesn't pick files from test directory (JDK-only project have the same issue) netbeans doesn't pick changes from files in JDK tree - i.e if I add/change class name in JDK tree, netbeans still treated it as unresolved within test (JDK-only project have the same issue) -Dmitry On 2013-03-25 20:29, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several > areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK > is fairly fast and even though I personally mostly work in the HotSpot > tree, I tend to always clone and build the entire JDK forest. I find > this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and > Solaris configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think > a change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From volker.simonis at gmail.com Mon Mar 25 10:15:11 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 18:15:11 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: Hi Jesper, first of all I highly welcome your initiative! Nevertheless I have some questions: - Who will support these project files? As far as I can see, they will have to be updated at least every time a file will be added, renamed or deleted. Experience shows that such kind of project files tend to get outdated very fast. Do you have any ideas how this problem can be addressed? - Where will other platform configurations go to? Will they be all stored in "configurations.xml" - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, CC_INTERP, etc..)? Will they all have to go into the same "configurations.xml" It seems that the "configurations.xml" might get quite big and complex with all these configurations. Thank you and best regards, Volker On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson wrote: > Hi, > > Sorry for cross posting, but I think this could be useful for several areas. > > I would like to add Solaris Studio / NetBeans project files for the entire > OpenJDK project. To clarify: One project that contains the entire OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK is > fairly fast and even though I personally mostly work in the HotSpot tree, I > tend to always clone and build the entire JDK forest. I find this to have > several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper From vladimir.voskresensky at oracle.com Mon Mar 25 10:01:37 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky - Oracle) Date: Mon, 25 Mar 2013 21:01:37 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <4C13F400-6CC9-456D-BFCA-2F7A32C769EC@oracle.com> References: <51507B60.6030809@oracle.com> <4C13F400-6CC9-456D-BFCA-2F7A32C769EC@oracle.com> Message-ID: <515082F1.70009@oracle.com> Meta files are auto adjusting to the current state of repository if do Clean&Build from IDE. Project is divided by configurations (per platform) The current one is for Mac-64. I've got it as base and now trying to create separate for Linux_64. Vladimir. On 03/25/13 08:51 PM, Mike Duigou wrote: > It's nice to see more work in this area and I was very pleased to see how small the project is. The configurations.xml file with it's long file lists worries me though. Is there any way to generate this information dynamically? I worry that the file lists wills be chronically forgotten and thus inevitably stale. > > Do you use this project mostly for editing or for building, testing and debugging as well? > > Mike > > On Mar 25 2013, at 09:29 , Jesper Wilhelmsson wrote: > >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several areas. >> >> I would like to add Solaris Studio / NetBeans project files for the entire OpenJDK project. To clarify: One project that contains the entire OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly fast and even though I personally mostly work in the HotSpot tree, I tend to always clone and build the entire JDK forest. I find this to have several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and Solaris configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I think a change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper From jesper.wilhelmsson at oracle.com Mon Mar 25 11:03:31 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 19:03:31 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: References: <51507B60.6030809@oracle.com> Message-ID: <51509173.6020803@oracle.com> Volker Simonis skrev 25/3/13 6:15 PM: > Hi Jesper, > > first of all I highly welcome your initiative! This is a joint initiative with Vladimir Voskresensky who works in the Solaris Studio team. > > Nevertheless I have some questions: > > - Who will support these project files? As far as I can see, they will > have to be updated at least every time a file will be added, renamed > or deleted. Experience shows that such kind of project files tend to > get outdated very fast. Do you have any ideas how this problem can be > addressed? One thing that was a pleasant surprise to me when I created the nbproject was that if I add new source files, they are automatically brought into the project. And when running make, the code assistant will be updated with the new definitions in the new files. So even if the project file is slightly out of date it will auto-update itself once you run make the first time. I don't think I should volunteer to keep the project files up to date, but since I will be using Solaris Studio for my daily work, and since I will be notified about changes in the project files every time I run "hg status", it seems pretty likely that I will push an updated project once in a while. - At least for Mac. > - Where will other platform configurations go to? Will they be all > stored in "configurations.xml" Yes, I think so. > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, > CC_INTERP, etc..)? Will they all have to go into the same > "configurations.xml" If I'm not mistaken these are different make targets, right? I don't think you need to have separate configurations saved in the project files for different make targets. Vladimir can answer this much better, but the way I have done it previously has simply been to edit the make command if I wanted to build a different target, and the code assistant is automatically updated when running make ("make clean" may be needed in some cases). > > It seems that the "configurations.xml" might get quite big and complex > with all these configurations. It's not too big right now IMHO. If it starts to grow unexpectedly in the future I agree that we should reconsider the choice to store it in the repository. Thank you for your comments, /Jesper > > Thank you and best regards, > Volker > > On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson > wrote: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several areas. >> >> I would like to add Solaris Studio / NetBeans project files for the entire >> OpenJDK project. To clarify: One project that contains the entire OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK is >> fairly fast and even though I personally mostly work in the HotSpot tree, I >> tend to always clone and build the entire JDK forest. I find this to have >> several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and Solaris >> configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I think a >> change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper From jesper.wilhelmsson at oracle.com Mon Mar 25 11:35:02 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 19:35:02 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51508545.6040102@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> Message-ID: <515098D6.4080404@oracle.com> Dmitry Samersoff skrev 25/3/13 6:11 PM: > Jesper, > > Tryed to apply your patch as I'm quite inetresting to have really > working NB project for jdk and hotspot. > > 1. Directory structure looks strange (see screenshot1) The structure in the Projects tab shows the NetBeans project hierarchy. It's not related to the OpenJDK project hierarchy. The "Files" tab (to the right of the project tab) will show you the directory structure as it looks on disk. I think this is the tab you want to use for browsing the directories. > 2. netbeans doesn't work for JDK tests (see screenshot2) - > > netbeans doesn't pick files > from test directory (JDK-only project have the same issue) > > netbeans doesn't pick changes from files in JDK tree - i.e > if I add/change class name in JDK tree, netbeans still treated it > as unresolved within test (JDK-only project have the same issue) I have mainly looked at the hotspot code when creating the project so I'm not surprised to see that there are things that don't work in for instance the jdk. I'll look at this tomorrow. Thank you for your comments, /Jesper > > -Dmitry > > > > On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several >> areas. >> >> I would like to add Solaris Studio / NetBeans project files for the >> entire OpenJDK project. To clarify: One project that contains the entire >> OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire OpenJDK >> is fairly fast and even though I personally mostly work in the HotSpot >> tree, I tend to always clone and build the entire JDK forest. I find >> this to have several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and >> Solaris configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I think >> a change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper > > From dmitry.samersoff at oracle.com Mon Mar 25 11:56:17 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Mar 2013 22:56:17 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <515098D6.4080404@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> <515098D6.4080404@oracle.com> Message-ID: <51509DD1.3020308@oracle.com> Jesper, On 2013-03-25 22:35, Jesper Wilhelmsson wrote: > Dmitry Samersoff skrev 25/3/13 6:11 PM: >> Jesper, >> >> Tryed to apply your patch as I'm quite inetresting to have really >> working NB project for jdk and hotspot. >> >> 1. Directory structure looks strange (see screenshot1) > > The structure in the Projects tab shows the NetBeans project hierarchy. > It's not related to the OpenJDK project hierarchy. The "Files" tab (to > the right of the project tab) will show you the directory structure as > it looks on disk. I think this is the tab you want to use for browsing > the directories. I'm using Linux and fresh netbeans copy, so fd and macosx_* projects comes from your patch for sure. Please take a look at it. -Dmitry > >> 2. netbeans doesn't work for JDK tests (see screenshot2) - >> >> netbeans doesn't pick files >> from test directory (JDK-only project have the same issue) >> >> netbeans doesn't pick changes from files in JDK tree - i.e >> if I add/change class name in JDK tree, netbeans still treated it >> as unresolved within test (JDK-only project have the same issue) > > I have mainly looked at the hotspot code when creating the project so > I'm not surprised to see that there are things that don't work in for > instance the jdk. I'll look at this tomorrow. > > Thank you for your comments, > /Jesper > >> >> -Dmitry >> >> >> >> On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several >>> areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the >>> entire OpenJDK project. To clarify: One project that contains the entire >>> OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK >>> is fairly fast and even though I personally mostly work in the HotSpot >>> tree, I tend to always clone and build the entire JDK forest. I find >>> this to have several benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and >>> Solaris configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I think >>> a change like this should go in. Let me know if you think something >>> else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From jesper.wilhelmsson at oracle.com Mon Mar 25 12:30:32 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 20:30:32 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51509DD1.3020308@oracle.com> References: <51507B60.6030809@oracle.com> <51508545.6040102@oracle.com> <515098D6.4080404@oracle.com> <51509DD1.3020308@oracle.com> Message-ID: <5150A5D8.1000800@oracle.com> Dmitry, Dmitry Samersoff skrev 25/3/13 7:56 PM: > Jesper, > > On 2013-03-25 22:35, Jesper Wilhelmsson wrote: >> Dmitry Samersoff skrev 25/3/13 6:11 PM: >>> Jesper, >>> >>> Tryed to apply your patch as I'm quite inetresting to have really >>> working NB project for jdk and hotspot. >>> >>> 1. Directory structure looks strange (see screenshot1) >> >> The structure in the Projects tab shows the NetBeans project hierarchy. >> It's not related to the OpenJDK project hierarchy. The "Files" tab (to >> the right of the project tab) will show you the directory structure as >> it looks on disk. I think this is the tab you want to use for browsing >> the directories. > > I'm using Linux and fresh netbeans copy, so fd and macosx_* projects > comes from your patch for sure. > > Please take a look at it. Sorry, I misinterpreted your initial comment. Yes, that is a bug. I have found the cause and will fix it. Thanks, /Jesper > > -Dmitry > >> >>> 2. netbeans doesn't work for JDK tests (see screenshot2) - >>> >>> netbeans doesn't pick files >>> from test directory (JDK-only project have the same issue) >>> >>> netbeans doesn't pick changes from files in JDK tree - i.e >>> if I add/change class name in JDK tree, netbeans still treated it >>> as unresolved within test (JDK-only project have the same issue) >> >> I have mainly looked at the hotspot code when creating the project so >> I'm not surprised to see that there are things that don't work in for >> instance the jdk. I'll look at this tomorrow. >> >> Thank you for your comments, >> /Jesper >> >>> >>> -Dmitry >>> >>> >>> >>> On 2013-03-25 20:29, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Sorry for cross posting, but I think this could be useful for several >>>> areas. >>>> >>>> I would like to add Solaris Studio / NetBeans project files for the >>>> entire OpenJDK project. To clarify: One project that contains the entire >>>> OpenJDK. >>>> >>>> >>>> With the new build infrastructure in JDK 8 building the entire OpenJDK >>>> is fairly fast and even though I personally mostly work in the HotSpot >>>> tree, I tend to always clone and build the entire JDK forest. I find >>>> this to have several benefits. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >>>> >>>> The configuration in this project is currently Mac only. Linux and >>>> Solaris configurations are also planned. >>>> >>>> The webrev is made from the jdk8/build repository which is where I think >>>> a change like this should go in. Let me know if you think something >>>> else. >>>> >>>> >>>> >>>> To use this project (once pushed): >>>> >>>> 1. Clone your favorite repository >>>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >>>> >>>> 2. Get the whole forest >>>> cd hotspot-gc >>>> sh get_source.sh >>>> >>>> 3. Configure >>>> sh configure >>>> >>>> 4. Open Solaris studio / NetBeans and load the project. >>>> The project in located in the common directory. >>>> >>>> >>>> Thanks, >>>> /Jesper >>> >>> > > From gnu.andrew at redhat.com Mon Mar 25 12:49:57 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Mar 2013 15:49:57 -0400 (EDT) Subject: PING: Re: Code Review Request: Simple new build system fix In-Reply-To: <514088B0.3080702@oracle.com> Message-ID: <704523776.23634640.1364240997123.JavaMail.root@redhat.com> ----- Original Message ----- > > > On 2013-03-13 15:01, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hello, > >> > >> I created a bug for you: > >> > >> 8009988: build-infra: Fix configure output for zip debuginfo check > >> > >> As David says, we haven't decided on 2.67, but I would guess that > >> a > >> majority of the commits have been with that version. This change > >> is a > >> first step towards enforcing a specific version and I'm ok with > >> that. > > Yes, I've been out of the loop a bit on this new build system. > > When I saw the huge diff my first attempt generated, I just assumed > > I should be using the same version that had been used previously. > > > >> The actual fix looks good to. You will still need a JDK reviewer > >> to > >> ok > >> it. Also, please notify me when you push this so that the closed > >> version > >> of the configure script may also be regenerated. > >> > > Ok, no problem. I await a review from someone like David or Kelly. > > > > Is there a preferred tree to push to? I spotted this when just > > trying > > to build so it's against jdk8 at the moment (which I obviously > > can't push > > to). Perhaps build? > > > Please use jdk8/build. > > /Erik > >> /Erik > >> > >> On 2013-03-13 13:18, Andrew Hughes wrote: > >>> I've finally found time to look at the new build system (well, > >>> there seems to no longer be any choice ;) > >>> and so thought I start out with a simple fix. > >>> > >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > >>> > >>> At the moment, if disable-zip-debug-info is not specified, the > >>> configure output is: > >>> > >>> checking if we should zip debug-info files... > >>> > >>> with no result as $enable_zip_debug_info is unset. > >>> > >>> This simple patch makes the option use the more standard > >>> AC_ARG_ENABLE form used elsewhere and will > >>> print the default ('yes') when the option is unspecified: > >>> > >>> checking if we should zip debug-info files... yes > >>> > >>> What actually took longer than the fix was updating the generated > >>> files. We seem to have already settled > >>> on autoconf 2.67 for generating the configure script, so my > >>> initial > >>> attempt threw up a huge number of changes > >>> as the system install is 2.69. I was able to get it down to > >>> something closer to what is expected by installing > >>> a local copy of 2.67 but it's still not perfect. I don't know > >>> why. > >>> I've never been a fan of including generated > >>> files for this reason. > >>> > >>> So this script also updates autogen.sh to see if there is an > >>> autoconf-2.67 available and use that in preference > >>> to autoconf if it is. I also added a little debug output so we > >>> can > >>> see which autoconf is being used in autogen.sh. > >>> > >>> If this is ok, can you please allocate it a bug ID and let me > >>> know > >>> which tree to commit it to. > >>> > >>> Thanks, > Any progress on this? Still needs a reviewer. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From volker.simonis at gmail.com Mon Mar 25 12:59:18 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 20:59:18 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51509173.6020803@oracle.com> References: <51507B60.6030809@oracle.com> <51509173.6020803@oracle.com> Message-ID: On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Volker Simonis skrev 25/3/13 6:15 PM: > > Hi Jesper, >> >> first of all I highly welcome your initiative! >> > > This is a joint initiative with Vladimir Voskresensky who works in the > Solaris Studio team. > > > >> Nevertheless I have some questions: >> >> - Who will support these project files? As far as I can see, they will >> have to be updated at least every time a file will be added, renamed >> or deleted. Experience shows that such kind of project files tend to >> get outdated very fast. Do you have any ideas how this problem can be >> addressed? >> > > One thing that was a pleasant surprise to me when I created the nbproject > was that if I add new source files, they are automatically brought into the > project. And when running make, the code assistant will be updated with the > new definitions in the new files. So even if the project file is slightly > out of date it will auto-update itself once you run make the first time. > > I don't think I should volunteer to keep the project files up to date, but > since I will be using Solaris Studio for my daily work, and since I will be > notified about changes in the project files every time I run "hg status", > it seems pretty likely that I will push an updated project once in a while. > - At least for Mac. > > > - Where will other platform configurations go to? Will they be all >> stored in "configurations.xml" >> > > Yes, I think so. > > > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, >> CC_INTERP, etc..)? Will they all have to go into the same >> "configurations.xml" >> > > If I'm not mistaken these are different make targets, right? I don't think > you need to have separate configurations saved in the project files for > different make targets. Vladimir can answer this much better, but the way I > have done it previously has simply been to edit the make command if I > wanted to build a different target, and the code assistant is automatically > updated when running make ("make clean" may be needed in some cases). > > These are partially make targets but also preprocessor defines set by various make targets. For example you may have different class definitions depending on whether "DEBUG" is defined or not. Actually I don't understand how code assistants is automatically updated if I do a "make clean" with a different make target if I haven't defined the new preprocessor defines for the project. Is this by parsing the generated libjvm.so? That's a neat feature of NetBeans but as far as I know it only works if the VM is compiled with '-g3' which HotSpot isn't by default. > > >> It seems that the "configurations.xml" might get quite big and complex >> with all these configurations. >> > > It's not too big right now IMHO. If it starts to grow unexpectedly in the > future I agree that we should reconsider the choice to store it in the > repository. > > Thank you for your comments, > /Jesper > > > >> Thank you and best regards, >> Volker >> >> On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson >> wrote: >> >>> Hi, >>> >>> Sorry for cross posting, but I think this could be useful for several >>> areas. >>> >>> I would like to add Solaris Studio / NetBeans project files for the >>> entire >>> OpenJDK project. To clarify: One project that contains the entire >>> OpenJDK. >>> >>> >>> With the new build infrastructure in JDK 8 building the entire OpenJDK is >>> fairly fast and even though I personally mostly work in the HotSpot >>> tree, I >>> tend to always clone and build the entire JDK forest. I find this to have >>> several benefits. >>> >>> Webrev: http://cr.openjdk.java.net/~**jwilhelm/7074926/webrev/ >>> >>> The configuration in this project is currently Mac only. Linux and >>> Solaris >>> configurations are also planned. >>> >>> The webrev is made from the jdk8/build repository which is where I think >>> a >>> change like this should go in. Let me know if you think something else. >>> >>> >>> >>> To use this project (once pushed): >>> >>> 1. Clone your favorite repository >>> hg clone http://hg.openjdk.java.net/**hsx/hotspot-gc >>> >>> 2. Get the whole forest >>> cd hotspot-gc >>> sh get_source.sh >>> >>> 3. Configure >>> sh configure >>> >>> 4. Open Solaris studio / NetBeans and load the project. >>> The project in located in the common directory. >>> >>> >>> Thanks, >>> /Jesper >>> >> From jesper.wilhelmsson at oracle.com Mon Mar 25 13:11:28 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 21:11:28 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: References: <51507B60.6030809@oracle.com> <51509173.6020803@oracle.com> Message-ID: <5150AF70.8080508@oracle.com> Volker Simonis skrev 25/3/13 8:59 PM: > > > On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson > > wrote: > > Volker Simonis skrev 25/3/13 6:15 PM: > > Hi Jesper, > > first of all I highly welcome your initiative! > > > This is a joint initiative with Vladimir Voskresensky who works in the > Solaris Studio team. > > > > Nevertheless I have some questions: > > - Who will support these project files? As far as I can see, they will > have to be updated at least every time a file will be added, renamed > or deleted. Experience shows that such kind of project files tend to > get outdated very fast. Do you have any ideas how this problem can be > addressed? > > > One thing that was a pleasant surprise to me when I created the nbproject > was that if I add new source files, they are automatically brought into the > project. And when running make, the code assistant will be updated with the > new definitions in the new files. So even if the project file is slightly > out of date it will auto-update itself once you run make the first time. > > I don't think I should volunteer to keep the project files up to date, but > since I will be using Solaris Studio for my daily work, and since I will be > notified about changes in the project files every time I run "hg status", it > seems pretty likely that I will push an updated project once in a while. > - At least for Mac. > > > - Where will other platform configurations go to? Will they be all > stored in "configurations.xml" > > > Yes, I think so. > > > - What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit, > CC_INTERP, etc..)? Will they all have to go into the same > "configurations.xml" > > > If I'm not mistaken these are different make targets, right? I don't think > you need to have separate configurations saved in the project files for > different make targets. Vladimir can answer this much better, but the way I > have done it previously has simply been to edit the make command if I wanted > to build a different target, and the code assistant is automatically updated > when running make ("make clean" may be needed in some cases). > > > These are partially make targets but also preprocessor defines set by various > make targets. For example you may have different class definitions depending on > whether "DEBUG" is defined or not. Actually I don't understand how code > assistants is automatically updated if I do a "make clean" with a different make > target if I haven't defined the new preprocessor defines for the project. Is > this by parsing the generated libjvm.so? That's a neat feature of NetBeans but > as far as I know it only works if the VM is compiled with '-g3' which HotSpot > isn't by default. In the current project all info about how the files are compiled are taken from the make logs. /Jesper > > > > It seems that the "configurations.xml" might get quite big and complex > with all these configurations. > > > It's not too big right now IMHO. If it starts to grow unexpectedly in the > future I agree that we should reconsider the choice to store it in the > repository. > > Thank you for your comments, > /Jesper > > > > Thank you and best regards, > Volker > > On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson > __> > wrote: > > Hi, > > Sorry for cross posting, but I think this could be useful for > several areas. > > I would like to add Solaris Studio / NetBeans project files for the > entire > OpenJDK project. To clarify: One project that contains the entire > OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire > OpenJDK is > fairly fast and even though I personally mostly work in the HotSpot > tree, I > tend to always clone and build the entire JDK forest. I find this to > have > several benefits. > > Webrev: http://cr.openjdk.java.net/~__jwilhelm/7074926/webrev/ > > > The configuration in this project is currently Mac only. Linux and > Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I > think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/__hsx/hotspot-gc > > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper > > From mandy.chung at oracle.com Mon Mar 25 13:11:37 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Mar 2013 13:11:37 -0700 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <511E0597.2080902@oracle.com> References: <511D73CA.90503@oracle.com> <511E0597.2080902@oracle.com> Message-ID: <5150AF79.9010206@oracle.com> On 2/15/13 1:53 AM, David Holmes wrote: > Hi Mandy, > > On 15/02/2013 9:31 AM, Mandy Chung wrote: >> Remove com.sun.servicetag that we no longer support. This includes >> updates the makefiles and so include build-infra to review this >> change. > > This will require a tweak to profile-rtjar-includes.txt once it gets > pushed next week. It won't cause any build problems though so it is > okay for us to do a follow up CR to make the adjustment. > David, I have modified profile-includes.txt and profile-rtjar-includes.txt: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.01/ Other files are the same as in webrev.00. Mandy > David > >> It's solely JDK implementation-specific that was added to >> support JDK product registration and service tag as legacy >> Sun-software requirement in 2007. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.00/ >> >> Thanks >> Mandy From tim.bell at oracle.com Mon Mar 25 15:29:54 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 25 Mar 2013 15:29:54 -0700 Subject: PING: Re: Code Review Request: Simple new build system fix In-Reply-To: <704523776.23634640.1364240997123.JavaMail.root@redhat.com> References: <704523776.23634640.1364240997123.JavaMail.root@redhat.com> Message-ID: <5150CFE2.1040702@oracle.com> On 03/25/13 12:49, Andrew Hughes wrote: > ----- Original Message ----- >> >> On 2013-03-13 15:01, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> I created a bug for you: >>>> >>>> 8009988: build-infra: Fix configure output for zip debuginfo check >>>> >>>> As David says, we haven't decided on 2.67, but I would guess that >>>> a >>>> majority of the commits have been with that version. This change >>>> is a >>>> first step towards enforcing a specific version and I'm ok with >>>> that. >>> Yes, I've been out of the loop a bit on this new build system. >>> When I saw the huge diff my first attempt generated, I just assumed >>> I should be using the same version that had been used previously. >>> >>>> The actual fix looks good to. You will still need a JDK reviewer >>>> to >>>> ok >>>> it. Also, please notify me when you push this so that the closed >>>> version >>>> of the configure script may also be regenerated. >>>> >>> Ok, no problem. I await a review from someone like David or Kelly. >>> >>> Is there a preferred tree to push to? I spotted this when just >>> trying >>> to build so it's against jdk8 at the moment (which I obviously >>> can't push >>> to). Perhaps build? >>> >> Please use jdk8/build. >> >> /Erik >>>> /Erik >>>> >>>> On 2013-03-13 13:18, Andrew Hughes wrote: >>>>> I've finally found time to look at the new build system (well, >>>>> there seems to no longer be any choice ;) >>>>> and so thought I start out with a simple fix. >>>>> >>>>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ >>>>> >>>>> At the moment, if disable-zip-debug-info is not specified, the >>>>> configure output is: >>>>> >>>>> checking if we should zip debug-info files... >>>>> >>>>> with no result as $enable_zip_debug_info is unset. >>>>> >>>>> This simple patch makes the option use the more standard >>>>> AC_ARG_ENABLE form used elsewhere and will >>>>> print the default ('yes') when the option is unspecified: >>>>> >>>>> checking if we should zip debug-info files... yes >>>>> >>>>> What actually took longer than the fix was updating the generated >>>>> files. We seem to have already settled >>>>> on autoconf 2.67 for generating the configure script, so my >>>>> initial >>>>> attempt threw up a huge number of changes >>>>> as the system install is 2.69. I was able to get it down to >>>>> something closer to what is expected by installing >>>>> a local copy of 2.67 but it's still not perfect. I don't know >>>>> why. >>>>> I've never been a fan of including generated >>>>> files for this reason. >>>>> >>>>> So this script also updates autogen.sh to see if there is an >>>>> autoconf-2.67 available and use that in preference >>>>> to autoconf if it is. I also added a little debug output so we >>>>> can >>>>> see which autoconf is being used in autogen.sh. >>>>> >>>>> If this is ok, can you please allocate it a bug ID and let me >>>>> know >>>>> which tree to commit it to. >>>>> >>>>> Thanks, > Any progress on this? Still needs a reviewer. > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ The fix looks good. Approved. Please push to the jdk8/build forest. Erik or I will take care of updating the closed generated-configure.sh file after we see your push. Tim From david.holmes at oracle.com Mon Mar 25 17:01:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 10:01:12 +1000 Subject: Review 8007703: Remove com.sun.servicetag API In-Reply-To: <5150AF79.9010206@oracle.com> References: <511D73CA.90503@oracle.com> <511E0597.2080902@oracle.com> <5150AF79.9010206@oracle.com> Message-ID: <5150E548.3040502@oracle.com> Hi Mandy, On 26/03/2013 6:11 AM, Mandy Chung wrote: > On 2/15/13 1:53 AM, David Holmes wrote: >> Hi Mandy, >> >> On 15/02/2013 9:31 AM, Mandy Chung wrote: >>> Remove com.sun.servicetag that we no longer support. This includes >>> updates the makefiles and so include build-infra to review this >>> change. >> >> This will require a tweak to profile-rtjar-includes.txt once it gets >> pushed next week. It won't cause any build problems though so it is >> okay for us to do a follow up CR to make the adjustment. >> > > David, > > I have modified profile-includes.txt and profile-rtjar-includes.txt: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.01/ > > Other files are the same as in webrev.00. This all looks good to me. Thanks, David > Mandy > >> David >> >>> It's solely JDK implementation-specific that was added to >>> support JDK product registration and service tag as legacy >>> Sun-software requirement in 2007. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007703/webrev.00/ >>> >>> Thanks >>> Mandy > From roger.riggs at oracle.com Tue Mar 26 14:32:14 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 26 Mar 2013 17:32:14 -0400 Subject: javac -Xlint Message-ID: <515213DE.5070000@oracle.com> Hi, What is the incantation for the JDK 8 build on the configure or make command to get javac to produce the lint output? Where is it described? Thanks, Roger From erik.joelsson at oracle.com Wed Mar 27 02:19:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 10:19:54 +0100 Subject: javac -Xlint In-Reply-To: <515213DE.5070000@oracle.com> References: <515213DE.5070000@oracle.com> Message-ID: <5152B9BA.20707@oracle.com> Support for this has not yet been added unfortunately. You will have to edit jdk/makefiles/Setup.gmk. /Erik On 2013-03-26 22:32, roger riggs wrote: > Hi, > > What is the incantation for the JDK 8 build on the configure or make > command > to get javac to produce the lint output? Where is it described? > > Thanks, Roger > From erik.joelsson at oracle.com Wed Mar 27 02:28:34 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 10:28:34 +0100 Subject: javac -Xlint In-Reply-To: <5152B9BA.20707@oracle.com> References: <515213DE.5070000@oracle.com> <5152B9BA.20707@oracle.com> Message-ID: <5152BBC2.3090805@oracle.com> I just realized and verified you can override the variable on the command line: make DISABLE_WARNINGS=-Xlint:all will produce a ton of warnings. /Erik On 2013-03-27 10:19, Erik Joelsson wrote: > Support for this has not yet been added unfortunately. You will have > to edit jdk/makefiles/Setup.gmk. > > /Erik > > On 2013-03-26 22:32, roger riggs wrote: >> Hi, >> >> What is the incantation for the JDK 8 build on the configure or make >> command >> to get javac to produce the lint output? Where is it described? >> >> Thanks, Roger >> From jesper.wilhelmsson at oracle.com Wed Mar 27 09:04:19 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 27 Mar 2013 17:04:19 +0100 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51507B60.6030809@oracle.com> References: <51507B60.6030809@oracle.com> Message-ID: <51531883.7070903@oracle.com> Hi, A new webrev is now available. The issues reported from the first review should be fixed and the project now contains configurations for both Linux_64 and Mac_64. To select configuration there is a dropdown menu next to the build button. http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ Thanks, /Jesper Jesper Wilhelmsson skrev 25/3/13 5:29 PM: > Hi, > > Sorry for cross posting, but I think this could be useful for several areas. > > I would like to add Solaris Studio / NetBeans project files for the entire > OpenJDK project. To clarify: One project that contains the entire OpenJDK. > > > With the new build infrastructure in JDK 8 building the entire OpenJDK is fairly > fast and even though I personally mostly work in the HotSpot tree, I tend to > always clone and build the entire JDK forest. I find this to have several benefits. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ > > The configuration in this project is currently Mac only. Linux and Solaris > configurations are also planned. > > The webrev is made from the jdk8/build repository which is where I think a > change like this should go in. Let me know if you think something else. > > > > To use this project (once pushed): > > 1. Clone your favorite repository > hg clone http://hg.openjdk.java.net/hsx/hotspot-gc > > 2. Get the whole forest > cd hotspot-gc > sh get_source.sh > > 3. Configure > sh configure > > 4. Open Solaris studio / NetBeans and load the project. > The project in located in the common directory. > > > Thanks, > /Jesper From vladimir.voskresensky at oracle.com Sat Mar 30 04:03:51 2013 From: vladimir.voskresensky at oracle.com (Vladimir Voskresensky) Date: Sat, 30 Mar 2013 15:03:51 +0400 Subject: RFR: Project files for Solaris Studio / NetBeans In-Reply-To: <51531883.7070903@oracle.com> References: <51507B60.6030809@oracle.com> <51531883.7070903@oracle.com> Message-ID: <5156C697.8060003@oracle.com> Jesper, It looks good and works for me on Linux_64. Some comments for others: before running IDE specify IDE_JAVAPATH env variable if want to navigate into some java/include files (value is the same as previously was known as ALT_BOOTDIR): #export IDE_JAVAPATH=/opt/jdk/latest7 after opening project, make sure you are switched to Linux configuration Thanks! Vladimir. On 03/27/2013 08:04 PM, Jesper Wilhelmsson wrote: > Hi, > > A new webrev is now available. The issues reported from the first > review should be fixed and the project now contains configurations for > both Linux_64 and Mac_64. > > To select configuration there is a dropdown menu next to the build > button. > > http://cr.openjdk.java.net/~jwilhelm/7074926/webrev.2/ > > Thanks, > /Jesper > > > Jesper Wilhelmsson skrev 25/3/13 5:29 PM: >> Hi, >> >> Sorry for cross posting, but I think this could be useful for several >> areas. >> >> I would like to add Solaris Studio / NetBeans project files for the >> entire >> OpenJDK project. To clarify: One project that contains the entire >> OpenJDK. >> >> >> With the new build infrastructure in JDK 8 building the entire >> OpenJDK is fairly >> fast and even though I personally mostly work in the HotSpot tree, I >> tend to >> always clone and build the entire JDK forest. I find this to have >> several benefits. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/ >> >> The configuration in this project is currently Mac only. Linux and >> Solaris >> configurations are also planned. >> >> The webrev is made from the jdk8/build repository which is where I >> think a >> change like this should go in. Let me know if you think something else. >> >> >> >> To use this project (once pushed): >> >> 1. Clone your favorite repository >> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc >> >> 2. Get the whole forest >> cd hotspot-gc >> sh get_source.sh >> >> 3. Configure >> sh configure >> >> 4. Open Solaris studio / NetBeans and load the project. >> The project in located in the common directory. >> >> >> Thanks, >> /Jesper