From Kelly.Ohair at Sun.COM Fri Jul 6 21:30:06 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 06 Jul 2007 14:30:06 -0700 Subject: [PATCH] enable -z defs usage on all Linux targets In-Reply-To: <20070523220025.48d8783c@enterprise.flameeyes.is-a-geek.org> References: <20070523220025.48d8783c@enterprise.flameeyes.is-a-geek.org> Message-ID: <468EB45E.1080505@sun.com> FYI... Filed bug 6577886 for this change, will try and integrate it soon. -kto Diego 'Flameeyes' Petten? wrote: > The gmk file currnetly allow usage of -z defs as LDFLAGS only for > arches that are not PPC and are not 64-bit, without any comment on why > this happens; counting that PPC Linux does not seem to be supported by > OpenJDK anyway at the moment, -z defs works *mostly* fine on AMD64 > Linux. > > Where mostly is referred to demos that links using gcc even when the > source code is C++, using the LIBCXX variable to fix the link; this > works fine, unless you use STATIC_CXX=false at build time to use > runtime link to libstdc++. > > The attached patch removes the conditionals and fixes the libstdc++ > build, allowing a safer build with -z defs enabled even on amd64. > > From lhofhansl at yahoo.com Fri Jul 6 20:15:19 2007 From: lhofhansl at yahoo.com (Lars) Date: Fri, 06 Jul 2007 13:15:19 -0700 Subject: b15 build failure on 32 bit Linux (GCC 4) Message-ID: <468EA2D7.9030209@yahoo.com> hotspot/src/cpu/i486/vm/assembler_i486.hpp causes an obvious build problem. "Address::" has to be removed from this (at line 161): #ifndef _LP64 Address::Address(address loc, RelocationHolder spec); #endif // _LP64 -- Lars From aalawi at cs.auckland.ac.nz Thu Jul 12 00:12:48 2007 From: aalawi at cs.auckland.ac.nz (Abraham Alawi) Date: Thu, 12 Jul 2007 12:12:48 +1200 Subject: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile? Message-ID: <46957200.9000907@cs.auckland.ac.nz> Hi Folks, i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER). Has anybody managed to accomplish this yet? Does the Bootstrap JDK have to be SUN JDK? Is it possible to cross-compile it on x86 for PPC? Any useful information will be much appreciated. Cheers, -- Abraham From ted at tedneward.com Thu Jul 12 03:26:45 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 11 Jul 2007 20:26:45 -0700 Subject: State of the build on Windows? Message-ID: <021201c7c434$7b4f8160$802ca8c0@XPWork> I get some conflicting input regarding the state of the build on a Windows box. Kelly?s blog of May 2007 implies that it?s broken; is that still the case? Beyond that, I have Cygwin and VS2003 installed on my box, and I pulled down and built GNU make 3.80. Things still seem to be kinda broken at a fundamental level, though?is there anything else I need to do (env vars, etc) that would need to be set? For example, the makefiles seem to want to use a default temp directory of C:\Documents and Settings\Ted\Local Settings\... which obviously has spaces in it; is this supposed to be corrected somewhere? Where?s the best place to override these settings? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: 7/11/2007 4:09 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From thunderaxiom at gmail.com Thu Jul 12 05:38:51 2007 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Thu, 12 Jul 2007 07:38:51 +0200 Subject: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile? In-Reply-To: <46957200.9000907@cs.auckland.ac.nz> References: <46957200.9000907@cs.auckland.ac.nz> Message-ID: <4695BE6B.3090600@gmail.com> Abraham Alawi skrev den 12-07-2007 02:12: > Hi Folks, > > i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER). > > Has anybody managed to accomplish this yet? Does the Bootstrap JDK have > to be SUN JDK? Is it possible to cross-compile it on x86 for PPC? Any > useful information will be much appreciated. > I have understood that the OpenJDK does not yet contain a PowerPC version of HotSpot, so you will not get a suitable JVM. IBM have a JVM for Linux on PowerPC which runs well on my iMac, and there are several Open Source java projects which may be available on your platform. -- Thorbj?rn From dan at fabulich.com Thu Jul 12 06:08:16 2007 From: dan at fabulich.com (Dan Fabulich) Date: Wed, 11 Jul 2007 23:08:16 -0700 (Pacific Daylight Time) Subject: State of the build on Windows? In-Reply-To: <021201c7c434$7b4f8160$802ca8c0@XPWork> References: <021201c7c434$7b4f8160$802ca8c0@XPWork> Message-ID: Ted Neward wrote: > I get some conflicting input regarding the state of the build on a Windows > box. Kelly?s blog of May 2007 implies that it?s broken; is that still the > case? Yes, it's still broken. We're missing a critical file (t2k.lib) from the binary plugs that makes doing the build impossible. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 Sadly, all of the engineering work has already been done to fix the build, but adding that file would require legal approval to fix (since they'd have to legally bless a new distribution). Last word from Sun seems to be that it's more likely that the relevant plug will become obsolete (perhaps in a month?) than that we'll get a working Windows plug. http://mail.openjdk.java.net/pipermail/discuss/2007-July/000102.html -Dan From gbenson at redhat.com Thu Jul 12 08:06:07 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 12 Jul 2007 09:06:07 +0100 Subject: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile? In-Reply-To: <46957200.9000907@cs.auckland.ac.nz> References: <46957200.9000907@cs.auckland.ac.nz> Message-ID: <20070712080606.GA3574@redhat.com> Hi Abraham, I'm currently working on getting OpenJDK built and running on PPC but unfortunately it's not simply a bootstrapping issue. For OpenJDK to build on a specific platform a fair amount of platform-specific code needs to be written. Look in hotspot/src/cpu and hotspot/src/os_cpu and you'll see what I mean. It's a massive job. Have a look at http://gbenson.livejournal.com/ if you want to track my progress. Cheers, Gary Abraham Alawi wrote: > Hi Folks, > > i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER). > > Has anybody managed to accomplish this yet? Does the Bootstrap JDK > have to be SUN JDK? Is it possible to cross-compile it on x86 for > PPC? Any useful information will be much appreciated. > > Cheers, > > -- Abraham From twisti at complang.tuwien.ac.at Thu Jul 12 08:41:46 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 12 Jul 2007 10:41:46 +0200 Subject: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile? In-Reply-To: <46957200.9000907@cs.auckland.ac.nz> References: <46957200.9000907@cs.auckland.ac.nz> Message-ID: <1184229706.3258.13.camel@localhost.localdomain> On Thu, 2007-07-12 at 12:12 +1200, Abraham Alawi wrote: > Hi Folks, > > i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER). > > Has anybody managed to accomplish this yet? Does the Bootstrap JDK have > to be SUN JDK? Is it possible to cross-compile it on x86 for PPC? Any > useful information will be much appreciated. Hi! I'm having a half-way compiled j2se running with CACAO on PowerPC. Maybe that is helpful for you: http://www.advogato.org/person/twisti/ https://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK - twisti From legba at bk.ru Fri Jul 13 07:00:37 2007 From: legba at bk.ru (=?koi8-r?Q?=F4=C9=CD?=) Date: Fri, 13 Jul 2007 11:00:37 +0400 Subject: How to build HotSpot JVM statically Message-ID: Hi! I want build HotSpot JVM statically. It's needful for running JVM on RH6.2, kernel 2.4.32, glibc2.1.3 Upgrade of kernel and glibc on this system is impossible!!! Which options I must use for building??? Thanx! Timofey ?????????? ? ????????????? ?????? ?? ???????@Mail.Ru http://r.mail.ru/cln3255/otvet.mail.ru/ From aph at redhat.com Fri Jul 13 10:56:09 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Jul 2007 11:56:09 +0100 Subject: How to build HotSpot JVM statically In-Reply-To: References: Message-ID: <18071.23113.476990.472388@zebedee.pink> ??? writes: > I want build HotSpot JVM statically. > > It's needful for running JVM on RH6.2, kernel 2.4.32, glibc2.1.3 > Upgrade of kernel and glibc on this system is impossible!!! > > Which options I must use for building??? It's going to be hard. Red Hat Linux 6 is an old-school LinuxThreads target, and I'm not sure that it would be a good idea to run a statically compiled version of HotSpot on such a beast. However, older versions of the JVM did run on that system, so I suppose you have a chance. But it makes far more sense to try building on the target system than to cross-compile. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Kelly.Ohair at Sun.COM Sat Jul 14 00:14:06 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 13 Jul 2007 17:14:06 -0700 Subject: State of the build on Windows? In-Reply-To: <021201c7c434$7b4f8160$802ca8c0@XPWork> References: <021201c7c434$7b4f8160$802ca8c0@XPWork> Message-ID: <4698154E.4040301@sun.com> Ted, You haven't given me anything to go on here, but I assume the t2k.lib problem is still going to block you on Windows. There are two efforts going on right now with regards to t2k.lib. The awt team is trying to get rid of our dependence on t2k in the OpenJDK, effectively one less plug. And I and a few others have also been trying to re-configure the binary plug download bundles to be smaller, sparse, legally self defining, include the t2k.lib, and be automatically built by the Makefiles on every formal promotion build. Since this changes the legal documents, it's taken longer than I had thought it would. I am not a lawyer, so I won't speak to the specific legal issues here. We tried for B14 then B15, couldn't get all the issues resolved in time, and also do all the test builds as we have to repeatedly merge and re-merge these changes. We didn't want to break the jdk7 product or the OpenJDK with these changes. Hopefully everything will be in place for B16 for the new binary plugs, which will help all platforms, but will include t2k.lib. But I can't promise B16, we are trying very hard to get it into B16. But t2k.lib doesn't have long to live, the awt team is progressing very well on removing our dependence on it. Which is the best solution of course. I apologize for how long this is taking, but we are trying to get it right, or as right as possible. Once these binary plug changes are in place, I'll send an email to the discuss and build alias with details, but more importantly, we will be able to add/subtract (hopefully only subtract) from the binary plugs as we go, without detailed legal review, or at least that's the goal. -kto Ted Neward wrote: > I get some conflicting input regarding the state of the build on a > Windows box. Kelly?s blog of May 2007 implies that it?s broken; is that > still the case? > > > > Beyond that, I have Cygwin and VS2003 installed on my box, and I pulled > down and built GNU make 3.80. Things still seem to be kinda broken at a > fundamental level, though?is there anything else I need to do (env vars, > etc) that would need to be set? For example, the makefiles seem to want > to use a default temp directory of C:\Documents and Settings\Ted\Local > Settings\... which obviously has spaces in it; is this supposed to be > corrected somewhere? Where?s the best place to override these settings? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: > 7/11/2007 4:09 PM > From Kelly.Ohair at Sun.COM Sat Jul 14 00:21:21 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 13 Jul 2007 17:21:21 -0700 Subject: Build README Message-ID: <46981701.3040009@sun.com> FYI... The very latest OpenJDK Build README should be accessaable with this: https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/README-builds.html But I'll attach it too just in case. -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at tedneward.com Sat Jul 14 04:13:21 2007 From: ted at tedneward.com (Ted Neward) Date: Fri, 13 Jul 2007 21:13:21 -0700 Subject: State of the build on Windows? In-Reply-To: <4698154E.4040301@sun.com> Message-ID: <06a901c7c5cd$535a1a90$802ca8c0@XPWork> You're right--I didn't give you much to go on. Here's where I'm at right now. I pulled down the latest SVN sources, fresh checkout from the trunk. I have MSVS 2003 installed on the box, no problems there. I can build the Hotspot JVM itself using the hotspot build files, no problems there with any of the debug/fastdebug/product tiered/core/compiler1/compiler2 combinations. Everybody happy. Trying to build the larger build (OpenJDK as a whole) yields problems. I had Cygwin on my system, with (I think) all the tools I needed from there as part of the install. (Is there a definitive list? I've seen some what-seem-to-be-conflicting lists.) I pulled down GNU Make 3.80, built it using MSVC 2003, and both its "batched" and "cygwin" modes gave me problems, the first with CreateProcess failures, the second with shell execution failures. I think this is a red herring, which is why I'm not giving you the lists of error reports. Interestingly, I don't even get to the t2k.lib problem, because when I pulled down the binary plugs for Windows, I got what appears to be a complete JDK 7 build, and *not* the necessary pieces to build it. By the way, as a workaround, I *think* one can use the import library tool that ships with MSVS2003 to build the t2k.lib (if it's just an import library for t2k.dll) to get around this problem--this is what I was trying to verify when I ran into the larger issues. I'm hoping that Dan (or anyone else who has successfully built the Windows build) can help walk me through some of the setup and build issues...? I realize it's a lot to ask, but I'm hoping to take the experiences here and document them all in a white paper for popular consumption. So I guess my questions, in order, are: (*) Do we have a complete list of tools necessary to build on Windows? So I can verify I have all the tools necessary? (*) Can somebody send me a GNU Make for Windows that works for them, so I can make sure it's not my weirdo-built version that's breaking? (*) Can somebody please verify that the version of the binary plugs for Window on the Sun site is correct and suitable for building? If it is, can you send me the URL to pull it down (because I obviously grabbed the wrong one)? If it's not, send me one that is? (*) If I need to customize my build environment, is j2se/make/jdk_generic_profile.sh the file to modify, or should I create a customized one (based on jdk_generic_profile.sh) and use that? What's going to work best with future changes to the build infrastructure? I've read the README several times, but I find myself still stuck. :-/ Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Friday, July 13, 2007 5:14 PM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: State of the build on Windows? > > Ted, > > You haven't given me anything to go on here, but I assume the t2k.lib > problem is still going to block you on Windows. > > There are two efforts going on right now with regards to t2k.lib. > The awt team is trying to get rid of our dependence on t2k in the OpenJDK, > effectively one less plug. > > And I and a few others have also been trying to re-configure the binary > plug > download bundles to be smaller, sparse, legally self defining, include the > t2k.lib, > and be automatically built by the Makefiles on every formal promotion > build. > > Since this changes the legal documents, it's taken longer than I had > thought it would. I am not a lawyer, so I won't speak to the specific > legal issues here. We tried for B14 then B15, couldn't get all the > issues resolved in time, and also do all the test builds as we have to > repeatedly merge and re-merge these changes. > We didn't want to break the jdk7 product or the OpenJDK with these > changes. > Hopefully everything will be in place for B16 for the new binary plugs, > which will help all platforms, but will include t2k.lib. > But I can't promise B16, we are trying very hard to get it into B16. > > But t2k.lib doesn't have long to live, the awt team is progressing very > well on removing our dependence on it. Which is the best solution of > course. > > I apologize for how long this is taking, but we are trying to get it > right, > or as right as possible. Once these binary plug changes are in place, > I'll send an email to the discuss and build alias with details, but > more importantly, we will be able to add/subtract (hopefully only > subtract) > from the binary plugs as we go, without detailed legal review, or at > least that's the goal. > > -kto > > Ted Neward wrote: > > I get some conflicting input regarding the state of the build on a > > Windows box. Kelly?s blog of May 2007 implies that it?s broken; is that > > still the case? > > > > > > > > Beyond that, I have Cygwin and VS2003 installed on my box, and I pulled > > down and built GNU make 3.80. Things still seem to be kinda broken at a > > fundamental level, though?is there anything else I need to do (env vars, > > etc) that would need to be set? For example, the makefiles seem to want > > to use a default temp directory of C:\Documents and Settings\Ted\Local > > Settings\... which obviously has spaces in it; is this supposed to be > > corrected somewhere? Where?s the best place to override these settings? > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: > > 7/11/2007 4:09 PM > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: 7/13/2007 > 3:41 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: 7/13/2007 3:41 PM From dan at fabulich.com Sat Jul 14 21:20:14 2007 From: dan at fabulich.com (Dan Fabulich) Date: Sat, 14 Jul 2007 14:20:14 -0700 (Pacific Daylight Time) Subject: State of the build on Windows? In-Reply-To: <06a901c7c5cd$535a1a90$802ca8c0@XPWork> References: <06a901c7c5cd$535a1a90$802ca8c0@XPWork> Message-ID: Ted Neward wrote: > I'm hoping that Dan (or anyone else who has successfully built the Windows > build) can help walk me through some of the setup and build issues...? I > realize it's a lot to ask, but I'm hoping to take the experiences here and > document them all in a white paper for popular consumption. I'm just an interested party; since I haven't successfully done a build on Windows, I don't yet feel confident in my ability to help other people do it. I got the t2k error running "make sanity" (as described in the README); once I saw that, I didn't try to go on and build the JDK. > (*) Can somebody please verify that the version of the binary plugs for > Window on the Sun site is correct and suitable for building? If it is, > can you send me the URL to pull it down (because I obviously grabbed the > wrong one)? If it's not, send me one that is? For now, we know that the currently available binary plug ISN'T suitable for building; Kelly and others at Sun have confirmed this. IMO, I suggest we just hold off for now, and wait until we get some build/plugs that someone at Sun says will build successfully. -Dan From Kelly.Ohair at Sun.COM Sun Jul 15 17:11:01 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 15 Jul 2007 10:11:01 -0700 Subject: State of the build on Windows? In-Reply-To: <06a901c7c5cd$535a1a90$802ca8c0@XPWork> References: <06a901c7c5cd$535a1a90$802ca8c0@XPWork> Message-ID: <469A5525.1030003@sun.com> See the Build README: https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/README-builds.html A few comments below. Ted Neward wrote: > You're right--I didn't give you much to go on. Here's where I'm at right > now. > > I pulled down the latest SVN sources, fresh checkout from the trunk. > > I have MSVS 2003 installed on the box, no problems there. > > I can build the Hotspot JVM itself using the hotspot build files, no > problems there with any of the debug/fastdebug/product > tiered/core/compiler1/compiler2 combinations. Everybody happy. > > Trying to build the larger build (OpenJDK as a whole) yields problems. > > I had Cygwin on my system, with (I think) all the tools I needed from there > as part of the install. (Is there a definitive list? I've seen some > what-seem-to-be-conflicting lists.) See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and more, the list should be in the openjdk build readme. I myself just download all of cygwin, which takes a long time but then I never have to worry about not having something > > I pulled down GNU Make 3.80, built it using MSVC 2003, and both its > "batched" and "cygwin" modes gave me problems, the first with CreateProcess > failures, the second with shell execution failures. I think this is a red > herring, which is why I'm not giving you the lists of error reports. > You should not need to build GNU make, however there is an issue with 3.80 on Windows where it doesn't work, due to it not accepting C:/ style paths. See http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.html Download a patched cygwin make binary from http://www.cmake.org/files/cygwin/make.exe And this is important: Start your 'make' from a cygwin shell window, NOT a Windows command window. > Interestingly, I don't even get to the t2k.lib problem, because when I > pulled down the binary plugs for Windows, I got what appears to be a > complete JDK 7 build, and *not* the necessary pieces to build it. > That is how the binary plugs are delivered right now, a jdk7 image. We are working on sparse binary plugs. > By the way, as a workaround, I *think* one can use the import library tool > that ships with MSVS2003 to build the t2k.lib (if it's just an import > library for t2k.dll) to get around this problem--this is what I was trying > to verify when I ran into the larger issues. If you can create a .lib file from a .dll, that should work, I didn't spend much time looking into this idea, wasn't sure how reliable it was. > > I'm hoping that Dan (or anyone else who has successfully built the Windows > build) can help walk me through some of the setup and build issues...? I > realize it's a lot to ask, but I'm hoping to take the experiences here and > document them all in a white paper for popular consumption. > Look at the BUILD Readme first. Then get 'make sanity' to pass. Unfortunately without a t2k.lib, you won't get past the sanity check. > So I guess my questions, in order, are: > (*) Do we have a complete list of tools necessary to build on Windows? So I > can verify I have all the tools necessary? > (*) Can somebody send me a GNU Make for Windows that works for them, so I > can make sure it's not my weirdo-built version that's breaking? > (*) Can somebody please verify that the version of the binary plugs for > Window on the Sun site is correct and suitable for building? If it is, can > you send me the URL to pull it down (because I obviously grabbed the wrong > one)? If it's not, send me one that is? > (*) If I need to customize my build environment, is > j2se/make/jdk_generic_profile.sh the file to modify, or should I create a > customized one (based on jdk_generic_profile.sh) and use that? What's going > to work best with future changes to the build infrastructure? > > I've read the README several times, but I find myself still stuck. :-/ I'm wondering if you have read the right README. What README are you refering too? -kto > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Friday, July 13, 2007 5:14 PM >> To: Ted Neward >> Cc: build-dev at openjdk.java.net >> Subject: Re: State of the build on Windows? >> >> Ted, >> >> You haven't given me anything to go on here, but I assume the t2k.lib >> problem is still going to block you on Windows. >> >> There are two efforts going on right now with regards to t2k.lib. >> The awt team is trying to get rid of our dependence on t2k in the OpenJDK, >> effectively one less plug. >> >> And I and a few others have also been trying to re-configure the binary >> plug >> download bundles to be smaller, sparse, legally self defining, include the >> t2k.lib, >> and be automatically built by the Makefiles on every formal promotion >> build. >> >> Since this changes the legal documents, it's taken longer than I had >> thought it would. I am not a lawyer, so I won't speak to the specific >> legal issues here. We tried for B14 then B15, couldn't get all the >> issues resolved in time, and also do all the test builds as we have to >> repeatedly merge and re-merge these changes. >> We didn't want to break the jdk7 product or the OpenJDK with these >> changes. >> Hopefully everything will be in place for B16 for the new binary plugs, >> which will help all platforms, but will include t2k.lib. >> But I can't promise B16, we are trying very hard to get it into B16. >> >> But t2k.lib doesn't have long to live, the awt team is progressing very >> well on removing our dependence on it. Which is the best solution of >> course. >> >> I apologize for how long this is taking, but we are trying to get it >> right, >> or as right as possible. Once these binary plug changes are in place, >> I'll send an email to the discuss and build alias with details, but >> more importantly, we will be able to add/subtract (hopefully only >> subtract) >> from the binary plugs as we go, without detailed legal review, or at >> least that's the goal. >> >> -kto >> >> Ted Neward wrote: >>> I get some conflicting input regarding the state of the build on a >>> Windows box. Kelly?s blog of May 2007 implies that it?s broken; is that >>> still the case? >>> >>> >>> >>> Beyond that, I have Cygwin and VS2003 installed on my box, and I pulled >>> down and built GNU make 3.80. Things still seem to be kinda broken at a >>> fundamental level, though?is there anything else I need to do (env vars, >>> etc) that would need to be set? For example, the makefiles seem to want >>> to use a default temp directory of C:\Documents and Settings\Ted\Local >>> Settings\... which obviously has spaces in it; is this supposed to be >>> corrected somewhere? Where?s the best place to override these settings? >>> >>> >>> >>> Ted Neward >>> >>> Java, .NET, XML Services >>> >>> Consulting, Teaching, Speaking, Writing >>> >>> http://www.tedneward.com >>> >>> >>> >>> >>> >>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: >>> 7/11/2007 4:09 PM >>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: 7/13/2007 >> 3:41 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: 7/13/2007 > 3:41 PM > > From ted at tedneward.com Mon Jul 16 09:39:06 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 02:39:06 -0700 Subject: State of the build on Windows? In-Reply-To: <469A5525.1030003@sun.com> Message-ID: <002e01c7c78d$2944a830$802ca8c0@XPWork> > See the Build README: > > https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE > ADME-builds.html > That's the README, all right. :-) > See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and > more, the list should be in the openjdk build readme. > I myself just download all of cygwin, which takes a long time but > then I never have to worry about not having something > I guess I was assuming that the list there wasn't a comprehensive list, since there seemed to be a few things used in the build scripts that isn't on that list. (I can't point to anything now, of course, this was just an impression I got scanning through the build files.) > Download a patched cygwin make binary from > http://www.cmake.org/files/cygwin/make.exe > Done, thanks for the link. It reports .81, is that what it should report? > And this is important: Start your 'make' from a cygwin shell window, NOT a > Windows command window. > Been doing that. What would also be nice is to know what env vars should be set inside the Cygwin bash window; is there a definitive list of those, as well? Or are those what's inside the shell script that the README suggests to run? > That is how the binary plugs are delivered right now, a jdk7 image. > We are working on sparse binary plugs. > Ah... OK, that makes more sense. By the way, check out http://www.geocities.com/SiliconValley/5806/implib32.htm for a utility that will create an import library out of a DLL; it's freeware, but it does require that you have Visual C++ 2.x/4.x (which is very old compared to VS2003) on your path. (It uses DUMPBIN.EXE and LIB.EXE, both of which are in the VS2003 release.) Just run it against t2k.dll, and I *think* we're good to go for now. (Obviously I can't try it until I get past 'make sanity', either. ;-) ) > If you can create a .lib file from a .dll, that should work, I didn't > spend > much time looking into this idea, wasn't sure how reliable it was. > Assuming all that's needed there is the import definitions for the DLL itself (which is usually the case, given a .lib/.dll pairing like that), then we should be good to go, but obviously I can't say that for certain until I've built with it. Maybe Dan can have a go at it while I get past the other roadblocks...? (Dan, email me if you can't get the implib32 tool to work; I successfully generated a .lib for it, so I can mail that to you if you need it. I don't want to send it to the list "just in case" of licensing issues.) > I'm wondering if you have read the right README. What README are you > refering too? > Yep, that's the one. I just got thrown off by a few issues along the way. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Sunday, July 15, 2007 10:11 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: State of the build on Windows? > > See the Build README: > > > https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE > ADME-builds.html > > A few comments below. > > Ted Neward wrote: > > You're right--I didn't give you much to go on. Here's where I'm at right > > now. > > > > I pulled down the latest SVN sources, fresh checkout from the trunk. > > > > I have MSVS 2003 installed on the box, no problems there. > > > > I can build the Hotspot JVM itself using the hotspot build files, no > > problems there with any of the debug/fastdebug/product > > tiered/core/compiler1/compiler2 combinations. Everybody happy. > > > > Trying to build the larger build (OpenJDK as a whole) yields problems. > > > > I had Cygwin on my system, with (I think) all the tools I needed from > there > > as part of the install. (Is there a definitive list? I've seen some > > what-seem-to-be-conflicting lists.) > > See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and > more, the list should be in the openjdk build readme. > I myself just download all of cygwin, which takes a long time but > then I never have to worry about not having something > > > > > I pulled down GNU Make 3.80, built it using MSVC 2003, and both its > > "batched" and "cygwin" modes gave me problems, the first with > CreateProcess > > failures, the second with shell execution failures. I think this is a > red > > herring, which is why I'm not giving you the lists of error reports. > > > > You should not need to build GNU make, however there is an issue with 3.80 > on Windows where it doesn't work, due to it not accepting C:/ style paths. > See > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > ml > Download a patched cygwin make binary from > http://www.cmake.org/files/cygwin/make.exe > > And this is important: Start your 'make' from a cygwin shell window, NOT a > Windows command window. > > > > Interestingly, I don't even get to the t2k.lib problem, because when I > > pulled down the binary plugs for Windows, I got what appears to be a > > complete JDK 7 build, and *not* the necessary pieces to build it. > > > > That is how the binary plugs are delivered right now, a jdk7 image. > We are working on sparse binary plugs. > > > By the way, as a workaround, I *think* one can use the import library > tool > > that ships with MSVS2003 to build the t2k.lib (if it's just an import > > library for t2k.dll) to get around this problem--this is what I was > trying > > to verify when I ran into the larger issues. > > If you can create a .lib file from a .dll, that should work, I didn't > spend > much time looking into this idea, wasn't sure how reliable it was. > > > > > I'm hoping that Dan (or anyone else who has successfully built the > Windows > > build) can help walk me through some of the setup and build issues...? I > > realize it's a lot to ask, but I'm hoping to take the experiences here > and > > document them all in a white paper for popular consumption. > > > > Look at the BUILD Readme first. Then get 'make sanity' to pass. > Unfortunately without a t2k.lib, you won't get past the sanity check. > > > So I guess my questions, in order, are: > > (*) Do we have a complete list of tools necessary to build on Windows? > So I > > can verify I have all the tools necessary? > > (*) Can somebody send me a GNU Make for Windows that works for them, so > I > > can make sure it's not my weirdo-built version that's breaking? > > (*) Can somebody please verify that the version of the binary plugs for > > Window on the Sun site is correct and suitable for building? If it is, > can > > you send me the URL to pull it down (because I obviously grabbed the > wrong > > one)? If it's not, send me one that is? > > (*) If I need to customize my build environment, is > > j2se/make/jdk_generic_profile.sh the file to modify, or should I create > a > > customized one (based on jdk_generic_profile.sh) and use that? What's > going > > to work best with future changes to the build infrastructure? > > > > I've read the README several times, but I find myself still stuck. :-/ > > I'm wondering if you have read the right README. What README are you > refering too? > > -kto > > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > >> -----Original Message----- > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >> Sent: Friday, July 13, 2007 5:14 PM > >> To: Ted Neward > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: State of the build on Windows? > >> > >> Ted, > >> > >> You haven't given me anything to go on here, but I assume the t2k.lib > >> problem is still going to block you on Windows. > >> > >> There are two efforts going on right now with regards to t2k.lib. > >> The awt team is trying to get rid of our dependence on t2k in the > OpenJDK, > >> effectively one less plug. > >> > >> And I and a few others have also been trying to re-configure the binary > >> plug > >> download bundles to be smaller, sparse, legally self defining, include > the > >> t2k.lib, > >> and be automatically built by the Makefiles on every formal promotion > >> build. > >> > >> Since this changes the legal documents, it's taken longer than I had > >> thought it would. I am not a lawyer, so I won't speak to the specific > >> legal issues here. We tried for B14 then B15, couldn't get all the > >> issues resolved in time, and also do all the test builds as we have to > >> repeatedly merge and re-merge these changes. > >> We didn't want to break the jdk7 product or the OpenJDK with these > >> changes. > >> Hopefully everything will be in place for B16 for the new binary plugs, > >> which will help all platforms, but will include t2k.lib. > >> But I can't promise B16, we are trying very hard to get it into B16. > >> > >> But t2k.lib doesn't have long to live, the awt team is progressing very > >> well on removing our dependence on it. Which is the best solution of > >> course. > >> > >> I apologize for how long this is taking, but we are trying to get it > >> right, > >> or as right as possible. Once these binary plug changes are in place, > >> I'll send an email to the discuss and build alias with details, but > >> more importantly, we will be able to add/subtract (hopefully only > >> subtract) > >> from the binary plugs as we go, without detailed legal review, or at > >> least that's the goal. > >> > >> -kto > >> > >> Ted Neward wrote: > >>> I get some conflicting input regarding the state of the build on a > >>> Windows box. Kelly?s blog of May 2007 implies that it?s broken; is > that > >>> still the case? > >>> > >>> > >>> > >>> Beyond that, I have Cygwin and VS2003 installed on my box, and I > pulled > >>> down and built GNU make 3.80. Things still seem to be kinda broken at > a > >>> fundamental level, though?is there anything else I need to do (env > vars, > >>> etc) that would need to be set? For example, the makefiles seem to > want > >>> to use a default temp directory of C:\Documents and Settings\Ted\Local > >>> Settings\... which obviously has spaces in it; is this supposed to be > >>> corrected somewhere? Where?s the best place to override these > settings? > >>> > >>> > >>> > >>> Ted Neward > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: > >>> 7/11/2007 4:09 PM > >>> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > 7/13/2007 > >> 3:41 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > 7/13/2007 > > 3:41 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From Kelly.Ohair at Sun.COM Mon Jul 16 19:29:52 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 16 Jul 2007 12:29:52 -0700 Subject: State of the build on Windows? In-Reply-To: <002e01c7c78d$2944a830$802ca8c0@XPWork> References: <002e01c7c78d$2944a830$802ca8c0@XPWork> Message-ID: <469BC730.8050704@sun.com> Ted Neward wrote: >> See the Build README: >> >> https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE >> ADME-builds.html >> > That's the README, all right. :-) > >> See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and >> more, the list should be in the openjdk build readme. >> I myself just download all of cygwin, which takes a long time but >> then I never have to worry about not having something >> > I guess I was assuming that the list there wasn't a comprehensive list, > since there seemed to be a few things used in the build scripts that isn't > on that list. (I can't point to anything now, of course, this was just an > impression I got scanning through the build files.) It's hard to come up with a complete list, it's like having a complete list of all the Linux packages needed, very hard to nail down. If you see missing items, let me know and I'll file a bug to fix the README. > >> Download a patched cygwin make binary from >> http://www.cmake.org/files/cygwin/make.exe >> > Done, thanks for the link. It reports .81, is that what it should report? Not sure. If it works, it works, if it doesn't you won't get past the sanity. It will say something about a bad make rule because it sees the : in a C:/... path as a makefile target termination. Dies quickly. > >> And this is important: Start your 'make' from a cygwin shell window, NOT a >> Windows command window. >> > Been doing that. What would also be nice is to know what env vars should be > set inside the Cygwin bash window; is there a definitive list of those, as > well? Or are those what's inside the shell script that the README suggests > to run? What the shell script suggests, but the README is accurate even without using the shell script. Most settings (except PATH, LIB, INCLUDE) can just be passed in on the GNU make line, e.g. make ALT_BOOTDIR=C:/jdk1.6.0 ALT_... they don't have to be set in the environment, it's up to you. > >> That is how the binary plugs are delivered right now, a jdk7 image. >> We are working on sparse binary plugs. >> > Ah... OK, that makes more sense. By the way, check out > http://www.geocities.com/SiliconValley/5806/implib32.htm for a utility that > will create an import library out of a DLL; it's freeware, but it does > require that you have Visual C++ 2.x/4.x (which is very old compared to > VS2003) on your path. (It uses DUMPBIN.EXE and LIB.EXE, both of which are in > the VS2003 release.) Just run it against t2k.dll, and I *think* we're good > to go for now. (Obviously I can't try it until I get past 'make sanity', > either. ;-) ) Like I said, I won't be trying this, so please report back if it works. Out plan is to get rid of t2k.lib, or deliver it in the new binary plugs. I looked at this DLL-.LIB conversion, gave me the creeps, but I'm not a windows binary format expert, I'm a Unix Elf binary format kind of guy. ;^) > >> If you can create a .lib file from a .dll, that should work, I didn't >> spend >> much time looking into this idea, wasn't sure how reliable it was. >> > Assuming all that's needed there is the import definitions for the DLL > itself (which is usually the case, given a .lib/.dll pairing like that), > then we should be good to go, but obviously I can't say that for certain > until I've built with it. Maybe Dan can have a go at it while I get past the > other roadblocks...? (Dan, email me if you can't get the implib32 tool to > work; I successfully generated a .lib for it, so I can mail that to you if > you need it. I don't want to send it to the list "just in case" of licensing > issues.) > >> I'm wondering if you have read the right README. What README are you >> refering too? >> > Yep, that's the one. I just got thrown off by a few issues along the way. > If you have specific corrections for the README, please post them separately. I'll see what I can do, but the README isn't horrible high on my priority list right now. -kto > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Sunday, July 15, 2007 10:11 AM >> To: Ted Neward >> Cc: build-dev at openjdk.java.net >> Subject: Re: State of the build on Windows? >> >> See the Build README: >> >> >> https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE >> ADME-builds.html >> >> A few comments below. >> >> Ted Neward wrote: >>> You're right--I didn't give you much to go on. Here's where I'm at right >>> now. >>> >>> I pulled down the latest SVN sources, fresh checkout from the trunk. >>> >>> I have MSVS 2003 installed on the box, no problems there. >>> >>> I can build the Hotspot JVM itself using the hotspot build files, no >>> problems there with any of the debug/fastdebug/product >>> tiered/core/compiler1/compiler2 combinations. Everybody happy. >>> >>> Trying to build the larger build (OpenJDK as a whole) yields problems. >>> >>> I had Cygwin on my system, with (I think) all the tools I needed from >> there >>> as part of the install. (Is there a definitive list? I've seen some >>> what-seem-to-be-conflicting lists.) >> See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and >> more, the list should be in the openjdk build readme. >> I myself just download all of cygwin, which takes a long time but >> then I never have to worry about not having something >> >>> I pulled down GNU Make 3.80, built it using MSVC 2003, and both its >>> "batched" and "cygwin" modes gave me problems, the first with >> CreateProcess >>> failures, the second with shell execution failures. I think this is a >> red >>> herring, which is why I'm not giving you the lists of error reports. >>> >> You should not need to build GNU make, however there is an issue with 3.80 >> on Windows where it doesn't work, due to it not accepting C:/ style paths. >> See >> http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht >> ml >> Download a patched cygwin make binary from >> http://www.cmake.org/files/cygwin/make.exe >> >> And this is important: Start your 'make' from a cygwin shell window, NOT a >> Windows command window. >> >> >>> Interestingly, I don't even get to the t2k.lib problem, because when I >>> pulled down the binary plugs for Windows, I got what appears to be a >>> complete JDK 7 build, and *not* the necessary pieces to build it. >>> >> That is how the binary plugs are delivered right now, a jdk7 image. >> We are working on sparse binary plugs. >> >>> By the way, as a workaround, I *think* one can use the import library >> tool >>> that ships with MSVS2003 to build the t2k.lib (if it's just an import >>> library for t2k.dll) to get around this problem--this is what I was >> trying >>> to verify when I ran into the larger issues. >> If you can create a .lib file from a .dll, that should work, I didn't >> spend >> much time looking into this idea, wasn't sure how reliable it was. >> >>> I'm hoping that Dan (or anyone else who has successfully built the >> Windows >>> build) can help walk me through some of the setup and build issues...? I >>> realize it's a lot to ask, but I'm hoping to take the experiences here >> and >>> document them all in a white paper for popular consumption. >>> >> Look at the BUILD Readme first. Then get 'make sanity' to pass. >> Unfortunately without a t2k.lib, you won't get past the sanity check. >> >>> So I guess my questions, in order, are: >>> (*) Do we have a complete list of tools necessary to build on Windows? >> So I >>> can verify I have all the tools necessary? >>> (*) Can somebody send me a GNU Make for Windows that works for them, so >> I >>> can make sure it's not my weirdo-built version that's breaking? >>> (*) Can somebody please verify that the version of the binary plugs for >>> Window on the Sun site is correct and suitable for building? If it is, >> can >>> you send me the URL to pull it down (because I obviously grabbed the >> wrong >>> one)? If it's not, send me one that is? >>> (*) If I need to customize my build environment, is >>> j2se/make/jdk_generic_profile.sh the file to modify, or should I create >> a >>> customized one (based on jdk_generic_profile.sh) and use that? What's >> going >>> to work best with future changes to the build infrastructure? >>> >>> I've read the README several times, but I find myself still stuck. :-/ >> I'm wondering if you have read the right README. What README are you >> refering too? >> >> -kto >> >>> Ted Neward >>> Java, .NET, XML Services >>> Consulting, Teaching, Speaking, Writing >>> http://www.tedneward.com >>> >>>> -----Original Message----- >>>> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >>>> Sent: Friday, July 13, 2007 5:14 PM >>>> To: Ted Neward >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: State of the build on Windows? >>>> >>>> Ted, >>>> >>>> You haven't given me anything to go on here, but I assume the t2k.lib >>>> problem is still going to block you on Windows. >>>> >>>> There are two efforts going on right now with regards to t2k.lib. >>>> The awt team is trying to get rid of our dependence on t2k in the >> OpenJDK, >>>> effectively one less plug. >>>> >>>> And I and a few others have also been trying to re-configure the binary >>>> plug >>>> download bundles to be smaller, sparse, legally self defining, include >> the >>>> t2k.lib, >>>> and be automatically built by the Makefiles on every formal promotion >>>> build. >>>> >>>> Since this changes the legal documents, it's taken longer than I had >>>> thought it would. I am not a lawyer, so I won't speak to the specific >>>> legal issues here. We tried for B14 then B15, couldn't get all the >>>> issues resolved in time, and also do all the test builds as we have to >>>> repeatedly merge and re-merge these changes. >>>> We didn't want to break the jdk7 product or the OpenJDK with these >>>> changes. >>>> Hopefully everything will be in place for B16 for the new binary plugs, >>>> which will help all platforms, but will include t2k.lib. >>>> But I can't promise B16, we are trying very hard to get it into B16. >>>> >>>> But t2k.lib doesn't have long to live, the awt team is progressing very >>>> well on removing our dependence on it. Which is the best solution of >>>> course. >>>> >>>> I apologize for how long this is taking, but we are trying to get it >>>> right, >>>> or as right as possible. Once these binary plug changes are in place, >>>> I'll send an email to the discuss and build alias with details, but >>>> more importantly, we will be able to add/subtract (hopefully only >>>> subtract) >>>> from the binary plugs as we go, without detailed legal review, or at >>>> least that's the goal. >>>> >>>> -kto >>>> >>>> Ted Neward wrote: >>>>> I get some conflicting input regarding the state of the build on a >>>>> Windows box. Kelly?s blog of May 2007 implies that it?s broken; is >> that >>>>> still the case? >>>>> >>>>> >>>>> >>>>> Beyond that, I have Cygwin and VS2003 installed on my box, and I >> pulled >>>>> down and built GNU make 3.80. Things still seem to be kinda broken at >> a >>>>> fundamental level, though?is there anything else I need to do (env >> vars, >>>>> etc) that would need to be set? For example, the makefiles seem to >> want >>>>> to use a default temp directory of C:\Documents and Settings\Ted\Local >>>>> Settings\... which obviously has spaces in it; is this supposed to be >>>>> corrected somewhere? Where?s the best place to override these >> settings? >>>>> >>>>> >>>>> Ted Neward >>>>> >>>>> Java, .NET, XML Services >>>>> >>>>> Consulting, Teaching, Speaking, Writing >>>>> >>>>> http://www.tedneward.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> No virus found in this outgoing message. >>>>> Checked by AVG Free Edition. >>>>> Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: >>>>> 7/11/2007 4:09 PM >>>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: >> 7/13/2007 >>>> 3:41 PM >>>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: >> 7/13/2007 >>> 3:41 PM >>> >>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 >> 2:21 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > > From ted at tedneward.com Mon Jul 16 23:45:01 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 16:45:01 -0700 Subject: FW: State of the build on Windows? Message-ID: <01d701c7c803$559195d0$802ca8c0@XPWork> Resending, because I haven't seen it come through on the list.... Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Ted Neward [mailto:ted at tedneward.com] > Sent: Monday, July 16, 2007 2:39 AM > To: 'Kelly.Ohair at Sun.COM' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: State of the build on Windows? > > > See the Build README: > > > > > https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE > > ADME-builds.html > > > That's the README, all right. :-) > > > See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and > > more, the list should be in the openjdk build readme. > > I myself just download all of cygwin, which takes a long time but > > then I never have to worry about not having something > > > I guess I was assuming that the list there wasn't a comprehensive list, > since there seemed to be a few things used in the build scripts that isn't > on that list. (I can't point to anything now, of course, this was just an > impression I got scanning through the build files.) > > > Download a patched cygwin make binary from > > http://www.cmake.org/files/cygwin/make.exe > > > Done, thanks for the link. It reports .81, is that what it should report? > > > And this is important: Start your 'make' from a cygwin shell window, NOT > a > > Windows command window. > > > Been doing that. What would also be nice is to know what env vars should > be set inside the Cygwin bash window; is there a definitive list of those, > as well? Or are those what's inside the shell script that the README > suggests to run? > > > That is how the binary plugs are delivered right now, a jdk7 image. > > We are working on sparse binary plugs. > > > Ah... OK, that makes more sense. By the way, check out > http://www.geocities.com/SiliconValley/5806/implib32.htm for a utility > that will create an import library out of a DLL; it's freeware, but it > does require that you have Visual C++ 2.x/4.x (which is very old compared > to VS2003) on your path. (It uses DUMPBIN.EXE and LIB.EXE, both of which > are in the VS2003 release.) Just run it against t2k.dll, and I *think* > we're good to go for now. (Obviously I can't try it until I get past 'make > sanity', either. ;-) ) > > > If you can create a .lib file from a .dll, that should work, I didn't > > spend > > much time looking into this idea, wasn't sure how reliable it was. > > > Assuming all that's needed there is the import definitions for the DLL > itself (which is usually the case, given a .lib/.dll pairing like that), > then we should be good to go, but obviously I can't say that for certain > until I've built with it. Maybe Dan can have a go at it while I get past > the other roadblocks...? (Dan, email me if you can't get the implib32 tool > to work; I successfully generated a .lib for it, so I can mail that to you > if you need it. I don't want to send it to the list "just in case" of > licensing issues.) > > > I'm wondering if you have read the right README. What README are you > > refering too? > > > Yep, that's the one. I just got thrown off by a few issues along the way. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > > Sent: Sunday, July 15, 2007 10:11 AM > > To: Ted Neward > > Cc: build-dev at openjdk.java.net > > Subject: Re: State of the build on Windows? > > > > See the Build README: > > > > > > > https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE > > ADME-builds.html > > > > A few comments below. > > > > Ted Neward wrote: > > > You're right--I didn't give you much to go on. Here's where I'm at > right > > > now. > > > > > > I pulled down the latest SVN sources, fresh checkout from the trunk. > > > > > > I have MSVS 2003 installed on the box, no problems there. > > > > > > I can build the Hotspot JVM itself using the hotspot build files, no > > > problems there with any of the debug/fastdebug/product > > > tiered/core/compiler1/compiler2 combinations. Everybody happy. > > > > > > Trying to build the larger build (OpenJDK as a whole) yields problems. > > > > > > I had Cygwin on my system, with (I think) all the tools I needed from > > there > > > as part of the install. (Is there a definitive list? I've seen some > > > what-seem-to-be-conflicting lists.) > > > > See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and > > more, the list should be in the openjdk build readme. > > I myself just download all of cygwin, which takes a long time but > > then I never have to worry about not having something > > > > > > > > I pulled down GNU Make 3.80, built it using MSVC 2003, and both its > > > "batched" and "cygwin" modes gave me problems, the first with > > CreateProcess > > > failures, the second with shell execution failures. I think this is a > > red > > > herring, which is why I'm not giving you the lists of error reports. > > > > > > > You should not need to build GNU make, however there is an issue with > 3.80 > > on Windows where it doesn't work, due to it not accepting C:/ style > paths. > > See > > > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > > ml > > Download a patched cygwin make binary from > > http://www.cmake.org/files/cygwin/make.exe > > > > And this is important: Start your 'make' from a cygwin shell window, NOT > a > > Windows command window. > > > > > > > Interestingly, I don't even get to the t2k.lib problem, because when I > > > pulled down the binary plugs for Windows, I got what appears to be a > > > complete JDK 7 build, and *not* the necessary pieces to build it. > > > > > > > That is how the binary plugs are delivered right now, a jdk7 image. > > We are working on sparse binary plugs. > > > > > By the way, as a workaround, I *think* one can use the import library > > tool > > > that ships with MSVS2003 to build the t2k.lib (if it's just an import > > > library for t2k.dll) to get around this problem--this is what I was > > trying > > > to verify when I ran into the larger issues. > > > > If you can create a .lib file from a .dll, that should work, I didn't > > spend > > much time looking into this idea, wasn't sure how reliable it was. > > > > > > > > I'm hoping that Dan (or anyone else who has successfully built the > > Windows > > > build) can help walk me through some of the setup and build issues...? > I > > > realize it's a lot to ask, but I'm hoping to take the experiences here > > and > > > document them all in a white paper for popular consumption. > > > > > > > Look at the BUILD Readme first. Then get 'make sanity' to pass. > > Unfortunately without a t2k.lib, you won't get past the sanity check. > > > > > So I guess my questions, in order, are: > > > (*) Do we have a complete list of tools necessary to build on Windows? > > So I > > > can verify I have all the tools necessary? > > > (*) Can somebody send me a GNU Make for Windows that works for them, > so > > I > > > can make sure it's not my weirdo-built version that's breaking? > > > (*) Can somebody please verify that the version of the binary plugs > for > > > Window on the Sun site is correct and suitable for building? If it is, > > can > > > you send me the URL to pull it down (because I obviously grabbed the > > wrong > > > one)? If it's not, send me one that is? > > > (*) If I need to customize my build environment, is > > > j2se/make/jdk_generic_profile.sh the file to modify, or should I > create > > a > > > customized one (based on jdk_generic_profile.sh) and use that? What's > > going > > > to work best with future changes to the build infrastructure? > > > > > > I've read the README several times, but I find myself still stuck. :-/ > > > > I'm wondering if you have read the right README. What README are you > > refering too? > > > > -kto > > > > > > > > Ted Neward > > > Java, .NET, XML Services > > > Consulting, Teaching, Speaking, Writing > > > http://www.tedneward.com > > > > > >> -----Original Message----- > > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > > >> Sent: Friday, July 13, 2007 5:14 PM > > >> To: Ted Neward > > >> Cc: build-dev at openjdk.java.net > > >> Subject: Re: State of the build on Windows? > > >> > > >> Ted, > > >> > > >> You haven't given me anything to go on here, but I assume the t2k.lib > > >> problem is still going to block you on Windows. > > >> > > >> There are two efforts going on right now with regards to t2k.lib. > > >> The awt team is trying to get rid of our dependence on t2k in the > > OpenJDK, > > >> effectively one less plug. > > >> > > >> And I and a few others have also been trying to re-configure the > binary > > >> plug > > >> download bundles to be smaller, sparse, legally self defining, > include > > the > > >> t2k.lib, > > >> and be automatically built by the Makefiles on every formal promotion > > >> build. > > >> > > >> Since this changes the legal documents, it's taken longer than I had > > >> thought it would. I am not a lawyer, so I won't speak to the specific > > >> legal issues here. We tried for B14 then B15, couldn't get all the > > >> issues resolved in time, and also do all the test builds as we have > to > > >> repeatedly merge and re-merge these changes. > > >> We didn't want to break the jdk7 product or the OpenJDK with these > > >> changes. > > >> Hopefully everything will be in place for B16 for the new binary > plugs, > > >> which will help all platforms, but will include t2k.lib. > > >> But I can't promise B16, we are trying very hard to get it into B16. > > >> > > >> But t2k.lib doesn't have long to live, the awt team is progressing > very > > >> well on removing our dependence on it. Which is the best solution of > > >> course. > > >> > > >> I apologize for how long this is taking, but we are trying to get it > > >> right, > > >> or as right as possible. Once these binary plug changes are in place, > > >> I'll send an email to the discuss and build alias with details, but > > >> more importantly, we will be able to add/subtract (hopefully only > > >> subtract) > > >> from the binary plugs as we go, without detailed legal review, or at > > >> least that's the goal. > > >> > > >> -kto > > >> > > >> Ted Neward wrote: > > >>> I get some conflicting input regarding the state of the build on a > > >>> Windows box. Kelly?s blog of May 2007 implies that it?s broken; is > > that > > >>> still the case? > > >>> > > >>> > > >>> > > >>> Beyond that, I have Cygwin and VS2003 installed on my box, and I > > pulled > > >>> down and built GNU make 3.80. Things still seem to be kinda broken > at > > a > > >>> fundamental level, though?is there anything else I need to do (env > > vars, > > >>> etc) that would need to be set? For example, the makefiles seem to > > want > > >>> to use a default temp directory of C:\Documents and > Settings\Ted\Local > > >>> Settings\... which obviously has spaces in it; is this supposed to > be > > >>> corrected somewhere? Where?s the best place to override these > > settings? > > >>> > > >>> > > >>> > > >>> Ted Neward > > >>> > > >>> Java, .NET, XML Services > > >>> > > >>> Consulting, Teaching, Speaking, Writing > > >>> > > >>> http://www.tedneward.com > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> No virus found in this outgoing message. > > >>> Checked by AVG Free Edition. > > >>> Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: > > >>> 7/11/2007 4:09 PM > > >>> > > >> No virus found in this incoming message. > > >> Checked by AVG Free Edition. > > >> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > > 7/13/2007 > > >> 3:41 PM > > >> > > > > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > > 7/13/2007 > > > 3:41 PM > > > > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: > 7/15/2007 > > 2:21 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From ted at tedneward.com Mon Jul 16 23:51:03 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 16:51:03 -0700 Subject: State of the build on Windows? In-Reply-To: <469A5525.1030003@sun.com> Message-ID: <01dc01c7c804$2d6beaa0$802ca8c0@XPWork> Having installed the patched make, and having installed all of Cygwin, I then run "j2se/make/jdk_generic_profile.sh" and "cd control/make && make sanity" from a fresh bash prompt, and I get: sanity-rules.gmk:64: *** multiple target patterns. Stop. ? Is this another bad-environment problem? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Sunday, July 15, 2007 10:11 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: State of the build on Windows? > > See the Build README: > > > https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE > ADME-builds.html > > A few comments below. > > Ted Neward wrote: > > You're right--I didn't give you much to go on. Here's where I'm at right > > now. > > > > I pulled down the latest SVN sources, fresh checkout from the trunk. > > > > I have MSVS 2003 installed on the box, no problems there. > > > > I can build the Hotspot JVM itself using the hotspot build files, no > > problems there with any of the debug/fastdebug/product > > tiered/core/compiler1/compiler2 combinations. Everybody happy. > > > > Trying to build the larger build (OpenJDK as a whole) yields problems. > > > > I had Cygwin on my system, with (I think) all the tools I needed from > there > > as part of the install. (Is there a definitive list? I've seen some > > what-seem-to-be-conflicting lists.) > > See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and > more, the list should be in the openjdk build readme. > I myself just download all of cygwin, which takes a long time but > then I never have to worry about not having something > > > > > I pulled down GNU Make 3.80, built it using MSVC 2003, and both its > > "batched" and "cygwin" modes gave me problems, the first with > CreateProcess > > failures, the second with shell execution failures. I think this is a > red > > herring, which is why I'm not giving you the lists of error reports. > > > > You should not need to build GNU make, however there is an issue with 3.80 > on Windows where it doesn't work, due to it not accepting C:/ style paths. > See > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > ml > Download a patched cygwin make binary from > http://www.cmake.org/files/cygwin/make.exe > > And this is important: Start your 'make' from a cygwin shell window, NOT a > Windows command window. > > > > Interestingly, I don't even get to the t2k.lib problem, because when I > > pulled down the binary plugs for Windows, I got what appears to be a > > complete JDK 7 build, and *not* the necessary pieces to build it. > > > > That is how the binary plugs are delivered right now, a jdk7 image. > We are working on sparse binary plugs. > > > By the way, as a workaround, I *think* one can use the import library > tool > > that ships with MSVS2003 to build the t2k.lib (if it's just an import > > library for t2k.dll) to get around this problem--this is what I was > trying > > to verify when I ran into the larger issues. > > If you can create a .lib file from a .dll, that should work, I didn't > spend > much time looking into this idea, wasn't sure how reliable it was. > > > > > I'm hoping that Dan (or anyone else who has successfully built the > Windows > > build) can help walk me through some of the setup and build issues...? I > > realize it's a lot to ask, but I'm hoping to take the experiences here > and > > document them all in a white paper for popular consumption. > > > > Look at the BUILD Readme first. Then get 'make sanity' to pass. > Unfortunately without a t2k.lib, you won't get past the sanity check. > > > So I guess my questions, in order, are: > > (*) Do we have a complete list of tools necessary to build on Windows? > So I > > can verify I have all the tools necessary? > > (*) Can somebody send me a GNU Make for Windows that works for them, so > I > > can make sure it's not my weirdo-built version that's breaking? > > (*) Can somebody please verify that the version of the binary plugs for > > Window on the Sun site is correct and suitable for building? If it is, > can > > you send me the URL to pull it down (because I obviously grabbed the > wrong > > one)? If it's not, send me one that is? > > (*) If I need to customize my build environment, is > > j2se/make/jdk_generic_profile.sh the file to modify, or should I create > a > > customized one (based on jdk_generic_profile.sh) and use that? What's > going > > to work best with future changes to the build infrastructure? > > > > I've read the README several times, but I find myself still stuck. :-/ > > I'm wondering if you have read the right README. What README are you > refering too? > > -kto > > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > >> -----Original Message----- > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >> Sent: Friday, July 13, 2007 5:14 PM > >> To: Ted Neward > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: State of the build on Windows? > >> > >> Ted, > >> > >> You haven't given me anything to go on here, but I assume the t2k.lib > >> problem is still going to block you on Windows. > >> > >> There are two efforts going on right now with regards to t2k.lib. > >> The awt team is trying to get rid of our dependence on t2k in the > OpenJDK, > >> effectively one less plug. > >> > >> And I and a few others have also been trying to re-configure the binary > >> plug > >> download bundles to be smaller, sparse, legally self defining, include > the > >> t2k.lib, > >> and be automatically built by the Makefiles on every formal promotion > >> build. > >> > >> Since this changes the legal documents, it's taken longer than I had > >> thought it would. I am not a lawyer, so I won't speak to the specific > >> legal issues here. We tried for B14 then B15, couldn't get all the > >> issues resolved in time, and also do all the test builds as we have to > >> repeatedly merge and re-merge these changes. > >> We didn't want to break the jdk7 product or the OpenJDK with these > >> changes. > >> Hopefully everything will be in place for B16 for the new binary plugs, > >> which will help all platforms, but will include t2k.lib. > >> But I can't promise B16, we are trying very hard to get it into B16. > >> > >> But t2k.lib doesn't have long to live, the awt team is progressing very > >> well on removing our dependence on it. Which is the best solution of > >> course. > >> > >> I apologize for how long this is taking, but we are trying to get it > >> right, > >> or as right as possible. Once these binary plug changes are in place, > >> I'll send an email to the discuss and build alias with details, but > >> more importantly, we will be able to add/subtract (hopefully only > >> subtract) > >> from the binary plugs as we go, without detailed legal review, or at > >> least that's the goal. > >> > >> -kto > >> > >> Ted Neward wrote: > >>> I get some conflicting input regarding the state of the build on a > >>> Windows box. Kelly?s blog of May 2007 implies that it?s broken; is > that > >>> still the case? > >>> > >>> > >>> > >>> Beyond that, I have Cygwin and VS2003 installed on my box, and I > pulled > >>> down and built GNU make 3.80. Things still seem to be kinda broken at > a > >>> fundamental level, though?is there anything else I need to do (env > vars, > >>> etc) that would need to be set? For example, the makefiles seem to > want > >>> to use a default temp directory of C:\Documents and Settings\Ted\Local > >>> Settings\... which obviously has spaces in it; is this supposed to be > >>> corrected somewhere? Where?s the best place to override these > settings? > >>> > >>> > >>> > >>> Ted Neward > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: > >>> 7/11/2007 4:09 PM > >>> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > 7/13/2007 > >> 3:41 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: > 7/13/2007 > > 3:41 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From Martin.Buchholz at Sun.COM Tue Jul 17 00:09:35 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Mon, 16 Jul 2007 17:09:35 -0700 Subject: State of the build on Windows? In-Reply-To: <01dc01c7c804$2d6beaa0$802ca8c0@XPWork> References: <01dc01c7c804$2d6beaa0$802ca8c0@XPWork> Message-ID: <469C08BF.9070009@sun.com> Ted Neward wrote: > Having installed the patched make, and having installed all of Cygwin, I > then run "j2se/make/jdk_generic_profile.sh" and "cd control/make && make > sanity" from a fresh bash prompt, and I get: > > sanity-rules.gmk:64: *** multiple target patterns. Stop. > > ? Is this another bad-environment problem? Ted, I believe this is the problem referred to below. > You should not need to build GNU make, however there is an issue with 3.80 > on Windows where it doesn't work, due to it not accepting C:/ style paths. > See > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > ml > Download a patched cygwin make binary from > http://www.cmake.org/files/cygwin/make.exe Cygwin made a major controversial change to their make binary that causes make to no longer work with the JDK builds, or with any makefiles that use C:/FOO style paths. Martin > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >>-----Original Message----- >>From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >>Sent: Sunday, July 15, 2007 10:11 AM >>To: Ted Neward >>Cc: build-dev at openjdk.java.net >>Subject: Re: State of the build on Windows? >> >>See the Build README: >> >> >>https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/RE >>ADME-builds.html >> >>A few comments below. >> >>Ted Neward wrote: >>>You're right--I didn't give you much to go on. Here's where I'm at right >>>now. >>> >>>I pulled down the latest SVN sources, fresh checkout from the trunk. >>> >>>I have MSVS 2003 installed on the box, no problems there. >>> >>>I can build the Hotspot JVM itself using the hotspot build files, no >>>problems there with any of the debug/fastdebug/product >>>tiered/core/compiler1/compiler2 combinations. Everybody happy. >>> >>>Trying to build the larger build (OpenJDK as a whole) yields problems. >>> >>>I had Cygwin on my system, with (I think) all the tools I needed from >>there >>>as part of the install. (Is there a definitive list? I've seen some >>>what-seem-to-be-conflicting lists.) >>See the BUILD README. For sure you need the cygwin 'make', awk, ksh, and >>more, the list should be in the openjdk build readme. >>I myself just download all of cygwin, which takes a long time but >>then I never have to worry about not having something >> >>>I pulled down GNU Make 3.80, built it using MSVC 2003, and both its >>>"batched" and "cygwin" modes gave me problems, the first with >>CreateProcess >>>failures, the second with shell execution failures. I think this is a >>red >>>herring, which is why I'm not giving you the lists of error reports. >>> >>You should not need to build GNU make, however there is an issue with 3.80 >>on Windows where it doesn't work, due to it not accepting C:/ style paths. >>See >>http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht >>ml >>Download a patched cygwin make binary from >>http://www.cmake.org/files/cygwin/make.exe >> >>And this is important: Start your 'make' from a cygwin shell window, NOT a >>Windows command window. >> >> >>>Interestingly, I don't even get to the t2k.lib problem, because when I >>>pulled down the binary plugs for Windows, I got what appears to be a >>>complete JDK 7 build, and *not* the necessary pieces to build it. >>> >>That is how the binary plugs are delivered right now, a jdk7 image. >>We are working on sparse binary plugs. >> >>>By the way, as a workaround, I *think* one can use the import library >>tool >>>that ships with MSVS2003 to build the t2k.lib (if it's just an import >>>library for t2k.dll) to get around this problem--this is what I was >>trying >>>to verify when I ran into the larger issues. >>If you can create a .lib file from a .dll, that should work, I didn't >>spend >>much time looking into this idea, wasn't sure how reliable it was. >> >>>I'm hoping that Dan (or anyone else who has successfully built the >>Windows >>>build) can help walk me through some of the setup and build issues...? I >>>realize it's a lot to ask, but I'm hoping to take the experiences here >>and >>>document them all in a white paper for popular consumption. >>> >>Look at the BUILD Readme first. Then get 'make sanity' to pass. >>Unfortunately without a t2k.lib, you won't get past the sanity check. >> >>>So I guess my questions, in order, are: >>>(*) Do we have a complete list of tools necessary to build on Windows? >>So I >>>can verify I have all the tools necessary? >>>(*) Can somebody send me a GNU Make for Windows that works for them, so >>I >>>can make sure it's not my weirdo-built version that's breaking? >>>(*) Can somebody please verify that the version of the binary plugs for >>>Window on the Sun site is correct and suitable for building? If it is, >>can >>>you send me the URL to pull it down (because I obviously grabbed the >>wrong >>>one)? If it's not, send me one that is? >>>(*) If I need to customize my build environment, is >>>j2se/make/jdk_generic_profile.sh the file to modify, or should I create >>a >>>customized one (based on jdk_generic_profile.sh) and use that? What's >>going >>>to work best with future changes to the build infrastructure? >>> >>>I've read the README several times, but I find myself still stuck. :-/ >>I'm wondering if you have read the right README. What README are you >>refering too? >> >>-kto >> >>>Ted Neward >>>Java, .NET, XML Services >>>Consulting, Teaching, Speaking, Writing >>>http://www.tedneward.com >>> >>>>-----Original Message----- >>>>From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >>>>Sent: Friday, July 13, 2007 5:14 PM >>>>To: Ted Neward >>>>Cc: build-dev at openjdk.java.net >>>>Subject: Re: State of the build on Windows? >>>> >>>>Ted, >>>> >>>>You haven't given me anything to go on here, but I assume the t2k.lib >>>>problem is still going to block you on Windows. >>>> >>>>There are two efforts going on right now with regards to t2k.lib. >>>>The awt team is trying to get rid of our dependence on t2k in the >>OpenJDK, >>>>effectively one less plug. >>>> >>>>And I and a few others have also been trying to re-configure the binary >>>>plug >>>>download bundles to be smaller, sparse, legally self defining, include >>the >>>>t2k.lib, >>>>and be automatically built by the Makefiles on every formal promotion >>>>build. >>>> >>>>Since this changes the legal documents, it's taken longer than I had >>>>thought it would. I am not a lawyer, so I won't speak to the specific >>>>legal issues here. We tried for B14 then B15, couldn't get all the >>>>issues resolved in time, and also do all the test builds as we have to >>>>repeatedly merge and re-merge these changes. >>>>We didn't want to break the jdk7 product or the OpenJDK with these >>>>changes. >>>>Hopefully everything will be in place for B16 for the new binary plugs, >>>>which will help all platforms, but will include t2k.lib. >>>>But I can't promise B16, we are trying very hard to get it into B16. >>>> >>>>But t2k.lib doesn't have long to live, the awt team is progressing very >>>>well on removing our dependence on it. Which is the best solution of >>>>course. >>>> >>>>I apologize for how long this is taking, but we are trying to get it >>>>right, >>>>or as right as possible. Once these binary plug changes are in place, >>>>I'll send an email to the discuss and build alias with details, but >>>>more importantly, we will be able to add/subtract (hopefully only >>>>subtract) >>>>from the binary plugs as we go, without detailed legal review, or at >>>>least that's the goal. >>>> >>>>-kto >>>> >>>>Ted Neward wrote: >>>>>I get some conflicting input regarding the state of the build on a >>>>>Windows box. Kelly?s blog of May 2007 implies that it?s broken; is >>that >>>>>still the case? >>>>> >>>>> >>>>> >>>>>Beyond that, I have Cygwin and VS2003 installed on my box, and I >>pulled >>>>>down and built GNU make 3.80. Things still seem to be kinda broken at >>a >>>>>fundamental level, though?is there anything else I need to do (env >>vars, >>>>>etc) that would need to be set? For example, the makefiles seem to >>want >>>>>to use a default temp directory of C:\Documents and Settings\Ted\Local >>>>>Settings\... which obviously has spaces in it; is this supposed to be >>>>>corrected somewhere? Where?s the best place to override these >>settings? >>>>> >>>>> >>>>>Ted Neward >>>>> >>>>>Java, .NET, XML Services >>>>> >>>>>Consulting, Teaching, Speaking, Writing >>>>> >>>>>http://www.tedneward.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>No virus found in this outgoing message. >>>>>Checked by AVG Free Edition. >>>>>Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: >>>>>7/11/2007 4:09 PM >>>>> >>>>No virus found in this incoming message. >>>>Checked by AVG Free Edition. >>>>Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: >>7/13/2007 >>>>3:41 PM >>>> >>>No virus found in this outgoing message. >>>Checked by AVG Free Edition. >>>Version: 7.5.476 / Virus Database: 269.10.5/899 - Release Date: >>7/13/2007 >>>3:41 PM >>> >>> >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 >>2:21 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > > From ted at tedneward.com Tue Jul 17 00:38:32 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 17:38:32 -0700 Subject: State of the build on Windows? In-Reply-To: <469C08BF.9070009@sun.com> Message-ID: <021d01c7c80a$cfcb64f0$802ca8c0@XPWork> Aha--I had pulled down that patched make, but it wasn't on the path. Stupid. When I build now, I get a ton of WARNING and ERROR reports. How many of these do I care about? (Full list below, partial list here.) ERROR: You do not have access to the Microsoft Layer for Unicode (MSLU) runtime files. Please check your access to /jre/bin/unicows.dll and/or check your value of ALT_UNICOWS_DLL_PATH ERROR: You do not have access to msvcrt.dll. Please check your access to C:/windows/system32/msvcrt.dll and/or check your value of ALT_MSVCRT_DLL_PATH. ERROR: You do not have access to msvcr71.dll. Please check your access to C:/windows/system32/msvcr71.dll and/or check your value of ALT_MSVCR71_DLL_PATH. ERROR: Your JAVA_HOME environment variable is set. This will most likely cause the build to fail. Please unset it and start your build again. ERROR: Can't locate pre-built libraries. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/bin and/or check your value of ALT_CLOSED_LIB_DIR. ERROR: Can't locate pre-built libraries. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar and/or check your value of ALT_CLOSED_JAR_FILE. ERROR: Can't locate t2k import library. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/bin/t2k.lib and/or check your value of ALT_CLOSED_LIB_DIR. Obviously JAVA_HOME and the DLL_PATH errors are easy to fix; the BinaryPlugs errors confuse me, though, given that the binary plugs install with a jdk1.7.0 prefix; am I correct that I need to point ALT_CLOSED_LIB_DIR to C:\Prg\OpenJDK\BinaryPlugs\jdk1.7.0? And is UNICOWS still needed? I thought that was for Unicode support on Win95; do we still need it in the all-NT world we find ourselves in today? And why does it tell me it's looking in "/jre/bin"? While we're at it, the SLASH_JAVA variable--obviously it's pointing to a shared drive inside of Sun; do I need to set that to something in order for my setup to work? Sorry for the hopelessly-dumb questions, I'm just trying to understand the build process as a whole more, and (hopefully) put some more information into the archives so others won't have to look so stupid. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com Full sanity report: CYGWIN:XPJAVA:Ted[285] cd control/make && make sanity make[1]: Entering directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' make[1]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' Build Machine Information: build machine = XPJAVA Build Directory Structure: CWD = /cygdrive/c/Prg/openjdk/openjdk/control/make TOPDIR = ../.. CONTROL_TOPDIR = ../../control HOTSPOT_TOPDIR = ../../hotspot J2SE_TOPDIR = ../../j2se Build Directives: BUILD_HOTSPOT = true BUILD_J2SE = true Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/outputdir HOTSPOT_EXPORT_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import Bootstrap Settings: BOOTDIR = C:\Prg\jdk1.6.0 ALT_BOOTDIR = C:\Prg\jdk1.6.0 BOOT_VER = 1.6 [requires at least 1.5] OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 ALT_OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 ABS_OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 Build Tool Settings: SLASH_JAVA = J: ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = J:/devtools ALT_JDK_DEVTOOLS_DIR = UNIXCOMMAND_PATH = /usr/bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = C:/Prg/MSVS2003/VC7/Bin/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = MSVCRT_DLL_PATH = C:/windows/system32/msvcrt.dll ALT_MSVCRT_DLL_PATH = C:\windows\system32\msvcrt.dll MSVCR71_DLL_PATH = C:/windows/system32/msvcr71.dll ALT_MSVCR71_DLL_PATH = C:\windows\system32\msvcr71.dll MSDEVTOOLS_PATH = C:/Prg/MSVS2003/VC7/Bin/ ALT_MSDEVTOOLS_PATH = COMPILER_NAME = Visual Studio .NET 2003 Professional C++ COMPILER_VERSION = VS2003 CC_VER = 13.10.3077 [requires at least 13.10.3077] ZIP_VER = 2.32 [requires at least 2.2] UNZIP_VER = 5.52 [requires at least 5.12] LINK_VER = 7.10.3077 [requires at least 7.10.3077] PATH = /cygdrive/c/Prg/MSVS2003/Common7/IDE:/cygdrive/c/Prg/MSVS2003/VC7/BIN:/ cygdrive/c/Prg/MSVS2003/Common7/Tools:/cygdrive/c/Prg/MSVS2003/Common7/Tools /bin /prerelease:/cygdrive/c/Prg/MSVS2003/Common7/Tools/bin:/cygdrive/c/Prg/Micro soft .NET1.1/SDK/v1.1/bin:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322:/ cygd rive/c/prg/jEdit4.2:/cygdrive/c/Windows:/cygdrive/c/Windows/System32:/cygdri ve/c /Prg/Subversion-1.3.2/bin:/cygdrive/c/Prg/apache-ant-1.6.2/bin:/cygdrive/c/P rg/O penJDK/bin:/usr/bin:/cygdrive/c/Prg/MSVS2003/Vc7/bin:/cygdrive/c/Prg/MSVS200 3/Co mmon7/IDE:/cygdrive/c/Prg/MSVS2003/Common7/Tools/bin/prerelease:/cygdrive/c/ Prg/ MSVS2003/Common7/Tools:/cygdrive/c/Prg/MSVS2003/SDK/v1.1/bin:/cygdrive/c/Prg /MSV S2003/Common7/Tools/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WI NDOW S:/cygdrive/c/WINDOWS/System32/Wbem TEMPDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp Build Directives: USE_ONLY_BOOTDIR_TOOLS = USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = J2RE_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = normal FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = 3 INCREMENTAL_BUILD = false CC_HIGHEST_OPT = -O2 CC_HIGHER_OPT = -O1 CC_LOWER_OPT = -O1 CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB -Fdc:/Prg/openjdk/openjdk/c ontrol/build/WINDOW~1/tmp/obj/.pdb -Fec:/Prg/openjdk/openjdk/control/build/WINDO W~1/tmp/obj/.obj -Fmc:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/obj/.map - W3 CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB -Fdc:/Prg/openjdk/openjdk/c ontrol/build/WINDOW~1/tmp/obj/.pdb -Fec:/Prg/openjdk/openjdk/control/build/WINDO W~1/tmp/obj/.obj -Fmc:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/obj/.map - W3 JAVA_BOOT = C:\Prg\jdk1.6.0/bin/java -client -Xmx383m -Xms128m -XX:PermSize=32 m -XX:MaxPermSize=160m JAVAC_BOOT = C:\Prg\jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J-client -J- Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -target 5 JAR_BOOT = C:\Prg\jdk1.6.0/bin/jar JAVAH_BOOT = C:\Prg\jdk1.6.0/bin/javah -J-XX:ThreadStackSize=768 -J-client -J- Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m JAVA = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/java -client -Xmx383m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m JAVAC = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/javac -J-XX:ThreadSt ackSize=768 -J-client -J-Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize =160m JAR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/jar JAVAH = Build Platform Settings: USER = Ted PLATFORM = windows ARCH = i586 LIBARCH = i386 ARCH_FAMILY = i586 ARCH_DATA_MODEL = 32 ARCHPROP = x86 PROCESSOR_ARCHITECTURE = x86 PROCESSOR_IDENTIFIER = x86 Family 6 Model 13 Stepping 8, GenuineIntel WINDOWS_VERSION = 5 1 Service Pack 2 WINDOWS_NT_VERSION_STRING = CYGWIN_NT USING_CYGWIN = true CYGWIN_VER = 5.1 [requires at least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 5 [requires at least 5] OS_NAME = nt TEMP_FREE_SPACE = 783328 FREE_SPACE = 783348 MB_OF_MEMORY = 511 GNU Make Settings: MAKE = make MAKE_VER = 3.81 [requires at least 3.78] MAKECMDGOALS = sanity MAKEFLAGS = w -- ARCH_DATA_MODEL=32 BUILD_MOTIF=false BUILD_HOTSPOT=true ALT_HOTSPOT_IMPORT_PATH=c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspo t/import ALT_OUTPUTDIR=c:/Prg/openjdk/openjdk/control/build/WINDOW~1 FULL_VERSION=1.7.0-i nternal-Ted_16_jul_2007_17_17-b00 JDK_BUILD_NUMBER=b00 BUILD_NUMBER=b00 MILESTONE=internal EXTERNALSANITYCONTROL=true HOTSPOT_IMPORT_CHECK=false SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-Ted_16_jul_2007_17_17-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = C:/PROGRA~1/Java JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs ALT_JDK_IMPORT_PATH = HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import ALT_HOTSPOT_IMPORT_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import HOTSPOT_CLIENT_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/jre/bin/client ALT_HOTSPOT_CLIENT_PATH = HOTSPOT_SERVER_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/jre/bin/server ALT_HOTSPOT_SERVER_PATH = HOTSPOT_LIB_PATH = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/lib ALT_HOTSPOT_LIB_PATH = DXSDK_VER = 0x0700 DXSDK_PATH = C:/Prg/DIRECT~1 ALT_DXSDK_PATH = C:\Prg\DirectX9SDK_062005 DXSDK_INCLUDE_PATH = C:/Prg/DIRECT~1/Include ALT_DXSDK_INCLUDE_PATH = DXSDK_LIB_PATH = C:/Prg/DIRECT~1/Lib ALT_DXSDK_LIB_PATH = UNICOWS_DLL_PATH = /jre/bin ALT_UNICOWS_DLL_PATH = UNICOWS_LIB_PATH = C:/Prg/MSVS2003/VC7/PlatformSDK/Lib ALT_UNICOWS_LIB_PATH = CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = CLOSED_BUILD_PATH = J:/re/j2se/1.7.0/promoted/latest/binaries ALT_CLOSED_BUILD_PATH = CLOSED_JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs ALT_CLOSED_JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs CLOSED_LIB_DIR = C:\Prg\OpenJDK\BinaryPlugs/jre/bin ALT_CLOSED_LIB_DIR = CLOSED_JAR_FILE = C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar ALT_CLOSED_JAR_FILE = WARNING: You appear to be using an unsupported version of Windows Professional 2 000. The supported version is Windows Professional 2000 5 0 Service Pack 4. You appear to be using 5 1 Service Pack 2 ERROR: You do not have access to the Microsoft Layer for Unicode (MSLU) runtime files. Please check your access to /jre/bin/unicows.dll and/or check your value of ALT_UNICOWS_DLL_PATH ERROR: You do not have access to msvcrt.dll. Please check your access to C:/windows/system32/msvcrt.dll and/or check your value of ALT_MSVCRT_DLL_PATH. ERROR: You do not have access to msvcr71.dll. Please check your access to C:/windows/system32/msvcr71.dll and/or check your value of ALT_MSVCR71_DLL_PATH. ERROR: Your JAVA_HOME environment variable is set. This will most likely cause the build to fail. Please unset it and start your build again. ERROR: Can't locate pre-built libraries. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/bin and/or check your value of ALT_CLOSED_LIB_DIR. ERROR: Can't locate pre-built libraries. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar and/or check your value of ALT_CLOSED_JAR_FILE. ERROR: Can't locate t2k import library. Please check your access to C:\Prg\OpenJDK\BinaryPlugs/jre/bin/t2k.lib and/or check your value of ALT_CLOSED_LIB_DIR. Exiting because of the above error(s). > -----Original Message----- > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > Sent: Monday, July 16, 2007 5:10 PM > To: Ted Neward > Cc: Kelly.Ohair at Sun.COM; build-dev at openjdk.java.net > Subject: Re: State of the build on Windows? > > > > Ted Neward wrote: > > Having installed the patched make, and having installed all of Cygwin, I > > then run "j2se/make/jdk_generic_profile.sh" and "cd control/make && make > > sanity" from a fresh bash prompt, and I get: > > > > sanity-rules.gmk:64: *** multiple target patterns. Stop. > > > > ? Is this another bad-environment problem? > > Ted, > > I believe this is the problem referred to below. > > > You should not need to build GNU make, however there is an issue with > 3.80 > > on Windows where it doesn't work, due to it not accepting C:/ style > paths. > > See > > > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > > ml > > Download a patched cygwin make binary from > > http://www.cmake.org/files/cygwin/make.exe > > Cygwin made a major controversial change to their make binary > that causes make to no longer work with the JDK builds, > or with any makefiles that use C:/FOO style paths. > > Martin > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From ted at tedneward.com Tue Jul 17 00:44:20 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 17:44:20 -0700 Subject: State of the build on Windows? In-Reply-To: <021d01c7c80a$cfcb64f0$802ca8c0@XPWork> Message-ID: <022201c7c80b$9ec58a10$802ca8c0@XPWork> I don't know if these are potential bugs, by the way, or just bad settings on my machine, but.... (*) My msvc* DLLs *are* in C:\Windows\System32; is this a case of make not being happy with C:/-style paths again? (*) The unicows.dll is present in the binary plugs, in jre/bin; do I need to set a path to find it, or should the build find it already? (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a .bat file I created on my machine). Should it be getting it from the Windows environment (is it getting reset somehow in the jdk_generic_profile shell script), and if not, should I set it myself again in jdk_generic_profile or something? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Ted Neward > Sent: Monday, July 16, 2007 5:39 PM > To: Martin.Buchholz at Sun.COM > Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM > Subject: RE: State of the build on Windows? > > Aha--I had pulled down that patched make, but it wasn't on the path. > Stupid. > > When I build now, I get a ton of WARNING and ERROR reports. How many of > these do I care about? (Full list below, partial list here.) > > ERROR: You do not have access to the Microsoft Layer for Unicode (MSLU) > runtime files. > Please check your access to > /jre/bin/unicows.dll > and/or check your value of ALT_UNICOWS_DLL_PATH > > ERROR: You do not have access to msvcrt.dll. > Please check your access to > C:/windows/system32/msvcrt.dll > and/or check your value of ALT_MSVCRT_DLL_PATH. > > ERROR: You do not have access to msvcr71.dll. > Please check your access to > C:/windows/system32/msvcr71.dll > and/or check your value of ALT_MSVCR71_DLL_PATH. > > ERROR: Your JAVA_HOME environment variable is set. This will > most likely cause the build to fail. Please unset it > and start your build again. > > ERROR: Can't locate pre-built libraries. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/bin > and/or check your value of ALT_CLOSED_LIB_DIR. > > ERROR: Can't locate pre-built libraries. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar > and/or check your value of ALT_CLOSED_JAR_FILE. > > ERROR: Can't locate t2k import library. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/bin/t2k.lib > and/or check your value of ALT_CLOSED_LIB_DIR. > > Obviously JAVA_HOME and the DLL_PATH errors are easy to fix; the > BinaryPlugs > errors confuse me, though, given that the binary plugs install with a > jdk1.7.0 prefix; am I correct that I need to point ALT_CLOSED_LIB_DIR to > C:\Prg\OpenJDK\BinaryPlugs\jdk1.7.0? > > And is UNICOWS still needed? I thought that was for Unicode support on > Win95; do we still need it in the all-NT world we find ourselves in today? > And why does it tell me it's looking in "/jre/bin"? > > While we're at it, the SLASH_JAVA variable--obviously it's pointing to a > shared drive inside of Sun; do I need to set that to something in order > for > my setup to work? > > Sorry for the hopelessly-dumb questions, I'm just trying to understand the > build process as a whole more, and (hopefully) put some more information > into the archives so others won't have to look so stupid. :-) > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > Full sanity report: > > CYGWIN:XPJAVA:Ted[285] cd control/make && make sanity > make[1]: Entering directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' > make[1]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' > > Build Machine Information: > build machine = XPJAVA > > Build Directory Structure: > CWD = /cygdrive/c/Prg/openjdk/openjdk/control/make > TOPDIR = ../.. > CONTROL_TOPDIR = ../../control > HOTSPOT_TOPDIR = ../../hotspot > J2SE_TOPDIR = ../../j2se > > Build Directives: > BUILD_HOTSPOT = true > BUILD_J2SE = true > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = > HOTSPOT_OUTPUTDIR = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/outputdir > HOTSPOT_EXPORT_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import > > > Bootstrap Settings: > BOOTDIR = C:\Prg\jdk1.6.0 > ALT_BOOTDIR = C:\Prg\jdk1.6.0 > BOOT_VER = 1.6 [requires at least 1.5] > OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 > ALT_OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 > ABS_OUTPUTDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1 > > Build Tool Settings: > SLASH_JAVA = J: > ALT_SLASH_JAVA = > VARIANT = OPT > JDK_DEVTOOLS_DIR = J:/devtools > ALT_JDK_DEVTOOLS_DIR = > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/Prg/MSVS2003/VC7/Bin/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRT_DLL_PATH = C:/windows/system32/msvcrt.dll > ALT_MSVCRT_DLL_PATH = C:\windows\system32\msvcrt.dll > MSVCR71_DLL_PATH = C:/windows/system32/msvcr71.dll > ALT_MSVCR71_DLL_PATH = C:\windows\system32\msvcr71.dll > MSDEVTOOLS_PATH = C:/Prg/MSVS2003/VC7/Bin/ > ALT_MSDEVTOOLS_PATH = > COMPILER_NAME = Visual Studio .NET 2003 Professional C++ > COMPILER_VERSION = VS2003 > CC_VER = 13.10.3077 [requires at least 13.10.3077] > ZIP_VER = 2.32 [requires at least 2.2] > UNZIP_VER = 5.52 [requires at least 5.12] > LINK_VER = 7.10.3077 [requires at least 7.10.3077] > PATH = > /cygdrive/c/Prg/MSVS2003/Common7/IDE:/cygdrive/c/Prg/MSVS2003/VC7/BIN:/ > cygdrive/c/Prg/MSVS2003/Common7/Tools:/cygdrive/c/Prg/MSVS2003/Common7/Too > ls > /bin > /prerelease:/cygdrive/c/Prg/MSVS2003/Common7/Tools/bin:/cygdrive/c/Prg/Mic > ro > soft > .NET1.1/SDK/v1.1/bin:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322 > :/ > cygd > rive/c/prg/jEdit4.2:/cygdrive/c/Windows:/cygdrive/c/Windows/System32:/cygd > ri > ve/c > /Prg/Subversion-1.3.2/bin:/cygdrive/c/Prg/apache-ant- > 1.6.2/bin:/cygdrive/c/P > rg/O > penJDK/bin:/usr/bin:/cygdrive/c/Prg/MSVS2003/Vc7/bin:/cygdrive/c/Prg/MSVS2 > 00 > 3/Co > mmon7/IDE:/cygdrive/c/Prg/MSVS2003/Common7/Tools/bin/prerelease:/cygdrive/ > c/ > Prg/ > MSVS2003/Common7/Tools:/cygdrive/c/Prg/MSVS2003/SDK/v1.1/bin:/cygdrive/c/P > rg > /MSV > S2003/Common7/Tools/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/ > WI > NDOW > S:/cygdrive/c/WINDOWS/System32/Wbem > TEMPDIR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp > > Build Directives: > USE_ONLY_BOOTDIR_TOOLS = > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > J2RE_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = -O2 > CC_HIGHER_OPT = -O1 > CC_LOWER_OPT = -O1 > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB > -Fdc:/Prg/openjdk/openjdk/c > ontrol/build/WINDOW~1/tmp/obj/.pdb > -Fec:/Prg/openjdk/openjdk/control/build/WINDO > W~1/tmp/obj/.obj > -Fmc:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/obj/.map - > W3 > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB > -Fdc:/Prg/openjdk/openjdk/c > ontrol/build/WINDOW~1/tmp/obj/.pdb > -Fec:/Prg/openjdk/openjdk/control/build/WINDO > W~1/tmp/obj/.obj > -Fmc:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/obj/.map - > W3 > JAVA_BOOT = C:\Prg\jdk1.6.0/bin/java -client -Xmx383m -Xms128m > -XX:PermSize=32 > m -XX:MaxPermSize=160m > JAVAC_BOOT = C:\Prg\jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J- > client > -J- > Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -target 5 > JAR_BOOT = C:\Prg\jdk1.6.0/bin/jar > JAVAH_BOOT = C:\Prg\jdk1.6.0/bin/javah -J-XX:ThreadStackSize=768 -J- > client > -J- > Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m > JAVA = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/java -client > -Xmx383m > -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m > JAVAC = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/javac > -J-XX:ThreadSt > ackSize=768 -J-client -J-Xmx383m -J-Xms128m -J-XX:PermSize=32m > -J-XX:MaxPermSize > =160m > JAR = c:/Prg/openjdk/openjdk/control/build/WINDOW~1/bin/jar > JAVAH = > > Build Platform Settings: > USER = Ted > PLATFORM = windows > ARCH = i586 > LIBARCH = i386 > ARCH_FAMILY = i586 > ARCH_DATA_MODEL = 32 > ARCHPROP = x86 > PROCESSOR_ARCHITECTURE = x86 > PROCESSOR_IDENTIFIER = x86 Family 6 Model 13 Stepping 8, GenuineIntel > WINDOWS_VERSION = 5 1 Service Pack 2 > WINDOWS_NT_VERSION_STRING = CYGWIN_NT > USING_CYGWIN = true > CYGWIN_VER = 5.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 5 [requires at least 5] > OS_NAME = nt > TEMP_FREE_SPACE = 783328 > FREE_SPACE = 783348 > MB_OF_MEMORY = 511 > > GNU Make Settings: > MAKE = make > MAKE_VER = 3.81 [requires at least 3.78] > MAKECMDGOALS = sanity > MAKEFLAGS = w -- ARCH_DATA_MODEL=32 BUILD_MOTIF=false BUILD_HOTSPOT=true > ALT_HOTSPOT_IMPORT_PATH=c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hots > po > t/import > ALT_OUTPUTDIR=c:/Prg/openjdk/openjdk/control/build/WINDOW~1 > FULL_VERSION=1.7.0-i > nternal-Ted_16_jul_2007_17_17-b00 JDK_BUILD_NUMBER=b00 BUILD_NUMBER=b00 > MILESTONE=internal EXTERNALSANITYCONTROL=true HOTSPOT_IMPORT_CHECK=false > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-Ted_16_jul_2007_17_17-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs > ALT_JDK_IMPORT_PATH = > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import > HOTSPOT_CLIENT_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/jre/bin/clien > t > ALT_HOTSPOT_CLIENT_PATH = > HOTSPOT_SERVER_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/jre/bin/serve > r > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = > c:/Prg/openjdk/openjdk/control/build/WINDOW~1/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0700 > DXSDK_PATH = C:/Prg/DIRECT~1 > ALT_DXSDK_PATH = C:\Prg\DirectX9SDK_062005 > DXSDK_INCLUDE_PATH = C:/Prg/DIRECT~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = C:/Prg/DIRECT~1/Lib > ALT_DXSDK_LIB_PATH = > UNICOWS_DLL_PATH = /jre/bin > ALT_UNICOWS_DLL_PATH = > UNICOWS_LIB_PATH = C:/Prg/MSVS2003/VC7/PlatformSDK/Lib > ALT_UNICOWS_LIB_PATH = > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > CLOSED_BUILD_PATH = J:/re/j2se/1.7.0/promoted/latest/binaries > ALT_CLOSED_BUILD_PATH = > CLOSED_JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs > ALT_CLOSED_JDK_IMPORT_PATH = C:\Prg\OpenJDK\BinaryPlugs > CLOSED_LIB_DIR = C:\Prg\OpenJDK\BinaryPlugs/jre/bin > ALT_CLOSED_LIB_DIR = > CLOSED_JAR_FILE = C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar > ALT_CLOSED_JAR_FILE = > > > WARNING: You appear to be using an unsupported version of Windows > Professional 2 > 000. > The supported version is Windows Professional 2000 5 0 Service > Pack > 4. > > You appear to be using 5 1 Service Pack 2 > > ERROR: You do not have access to the Microsoft Layer for Unicode (MSLU) > runtime files. > Please check your access to > /jre/bin/unicows.dll > and/or check your value of ALT_UNICOWS_DLL_PATH > > ERROR: You do not have access to msvcrt.dll. > Please check your access to > C:/windows/system32/msvcrt.dll > and/or check your value of ALT_MSVCRT_DLL_PATH. > > ERROR: You do not have access to msvcr71.dll. > Please check your access to > C:/windows/system32/msvcr71.dll > and/or check your value of ALT_MSVCR71_DLL_PATH. > > ERROR: Your JAVA_HOME environment variable is set. This will > most likely cause the build to fail. Please unset it > and start your build again. > > ERROR: Can't locate pre-built libraries. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/bin > and/or check your value of ALT_CLOSED_LIB_DIR. > > ERROR: Can't locate pre-built libraries. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/lib/rt.jar > and/or check your value of ALT_CLOSED_JAR_FILE. > > ERROR: Can't locate t2k import library. > Please check your access to > C:\Prg\OpenJDK\BinaryPlugs/jre/bin/t2k.lib > and/or check your value of ALT_CLOSED_LIB_DIR. > > Exiting because of the above error(s). > > > > -----Original Message----- > > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > > Sent: Monday, July 16, 2007 5:10 PM > > To: Ted Neward > > Cc: Kelly.Ohair at Sun.COM; build-dev at openjdk.java.net > > Subject: Re: State of the build on Windows? > > > > > > > > Ted Neward wrote: > > > Having installed the patched make, and having installed all of Cygwin, > I > > > then run "j2se/make/jdk_generic_profile.sh" and "cd control/make && > make > > > sanity" from a fresh bash prompt, and I get: > > > > > > sanity-rules.gmk:64: *** multiple target patterns. Stop. > > > > > > ? Is this another bad-environment problem? > > > > Ted, > > > > I believe this is the problem referred to below. > > > > > You should not need to build GNU make, however there is an issue with > > 3.80 > > > on Windows where it doesn't work, due to it not accepting C:/ style > > paths. > > > See > > > > > > http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.ht > > > ml > > > Download a patched cygwin make binary from > > > http://www.cmake.org/files/cygwin/make.exe > > > > Cygwin made a major controversial change to their make binary > > that causes make to no longer work with the JDK builds, > > or with any makefiles that use C:/FOO style paths. > > > > Martin > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From Martin.Buchholz at Sun.COM Tue Jul 17 00:57:17 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Mon, 16 Jul 2007 17:57:17 -0700 Subject: State of the build on Windows? In-Reply-To: <022201c7c80b$9ec58a10$802ca8c0@XPWork> References: <022201c7c80b$9ec58a10$802ca8c0@XPWork> Message-ID: <469C13ED.6050508@sun.com> Ted Neward wrote: > I don't know if these are potential bugs, by the way, or just bad settings > on my machine, but.... > (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a .bat file > I created on my machine). Should it be getting it from the Windows > environment (is it getting reset somehow in the jdk_generic_profile shell > script), and if not, should I set it myself again in jdk_generic_profile or > something? I believe we strongly discourage setting the JAVA_HOME environment variable, at least for JDK developers. Martin From ted at tedneward.com Tue Jul 17 01:03:30 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 18:03:30 -0700 Subject: State of the build on Windows? In-Reply-To: <469C13ED.6050508@sun.com> Message-ID: <022601c7c80e$4c402cc0$802ca8c0@XPWork> So... should I set it, or make sure it's NOT set, and ignore the error? :-) Only reason I ask, "make sanity" reports it as an error; are you saying it should not? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > Sent: Monday, July 16, 2007 5:57 PM > To: Ted Neward > Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM > Subject: Re: State of the build on Windows? > > > > Ted Neward wrote: > > I don't know if these are potential bugs, by the way, or just bad > settings > > on my machine, but.... > > > (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a .bat > file > > I created on my machine). Should it be getting it from the Windows > > environment (is it getting reset somehow in the jdk_generic_profile > shell > > script), and if not, should I set it myself again in jdk_generic_profile > or > > something? > > I believe we strongly discourage setting the JAVA_HOME > environment variable, at least for JDK developers. > > Martin > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From ted at tedneward.com Tue Jul 17 01:04:12 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 16 Jul 2007 18:04:12 -0700 Subject: State of the build on Windows? In-Reply-To: <469C13ED.6050508@sun.com> Message-ID: <022701c7c80e$64c70390$802ca8c0@XPWork> D'Oh! My bad, I suddenly re-read the error--I thought it was complaining about it NOT being set. Now your comment makes sense. Sorry. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > Sent: Monday, July 16, 2007 5:57 PM > To: Ted Neward > Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM > Subject: Re: State of the build on Windows? > > > > Ted Neward wrote: > > I don't know if these are potential bugs, by the way, or just bad > settings > > on my machine, but.... > > > (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a .bat > file > > I created on my machine). Should it be getting it from the Windows > > environment (is it getting reset somehow in the jdk_generic_profile > shell > > script), and if not, should I set it myself again in jdk_generic_profile > or > > something? > > I believe we strongly discourage setting the JAVA_HOME > environment variable, at least for JDK developers. > > Martin > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From aalawi at cs.auckland.ac.nz Tue Jul 17 04:42:47 2007 From: aalawi at cs.auckland.ac.nz (Abraham Alawi) Date: Tue, 17 Jul 2007 16:42:47 +1200 Subject: OpenJDK on PPC/PPC64 -- non-SUN Bootstrap JDK? Cross-compile? In-Reply-To: <20070712080606.GA3574@redhat.com> References: <46957200.9000907@cs.auckland.ac.nz> <20070712080606.GA3574@redhat.com> Message-ID: <469C48C7.8060600@cs.auckland.ac.nz> Gary Benson wrote: > Hi Abraham, > > I'm currently working on getting OpenJDK built and running on PPC but > unfortunately it's not simply a bootstrapping issue. For OpenJDK to > build on a specific platform a fair amount of platform-specific code > needs to be written. Look in hotspot/src/cpu and hotspot/src/os_cpu > and you'll see what I mean. It's a massive job. > > Have a look at http://gbenson.livejournal.com/ if you want to track > my progress. > > Cheers, > Gary > > Abraham Alawi wrote: > >> Hi Folks, >> >> i'm trying to compile OpenJDK on POWERPC (IBM OPENPOWER). >> >> Has anybody managed to accomplish this yet? Does the Bootstrap JDK >> have to be SUN JDK? Is it possible to cross-compile it on x86 for >> PPC? Any useful information will be much appreciated. >> >> Cheers, >> >> -- Abraham >> Thanks for your replies guys. Gary, keep up the good work, you are doing hell of job! IBM should sponsor you! ;) -- Abraham '''''''''''''''''''''''''''''''''''''''''''''''''''''' Abraham Alawi Unix/Linux Systems Administrator Computer Science University of Auckland e: aalawi at cs.auckland.ac.nz p: +64-9-373 7599, ext#: 87572 '''''''''''''''''''''''''''''''''''''''''''''''''''''' From ted at tedneward.com Tue Jul 17 08:39:52 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 17 Jul 2007 01:39:52 -0700 Subject: State of the build on Windows? In-Reply-To: <022701c7c80e$64c70390$802ca8c0@XPWork> Message-ID: <02cb01c7c84e$0d5d4890$802ca8c0@XPWork> WHEE-HAAAA! Success! (At least, so far--it's still going.) And yes, this is with the implib32-created t2k.lib file that I manually dropped into the binary plugs jre/bin directory. Sanity passed, and I'm assuming the rest of the build will work. (Boy, will I look stupid if it doesn't work after all, but....) Next question: doing a 'make' builds a product build; how do I get a build that defines all debug symbols? In other words, how do I get the various hotspot-build options (debug/fastdebug/product and core/compiler1/compiler2/tiered/etc) in the build? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Ted Neward > Sent: Monday, July 16, 2007 6:04 PM > To: Martin.Buchholz at Sun.COM > Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM > Subject: RE: State of the build on Windows? > > D'Oh! My bad, I suddenly re-read the error--I thought it was complaining > about it NOT being set. Now your comment makes sense. Sorry. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > > Sent: Monday, July 16, 2007 5:57 PM > > To: Ted Neward > > Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM > > Subject: Re: State of the build on Windows? > > > > > > > > Ted Neward wrote: > > > I don't know if these are potential bugs, by the way, or just bad > > settings > > > on my machine, but.... > > > > > (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a > .bat > > file > > > I created on my machine). Should it be getting it from the Windows > > > environment (is it getting reset somehow in the jdk_generic_profile > > shell > > > script), and if not, should I set it myself again in > jdk_generic_profile > > or > > > something? > > > > I believe we strongly discourage setting the JAVA_HOME > > environment variable, at least for JDK developers. > > > > Martin > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: > 7/15/2007 > > 2:21 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM From Kelly.Ohair at Sun.COM Tue Jul 17 14:32:55 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 17 Jul 2007 07:32:55 -0700 Subject: State of the build on Windows? In-Reply-To: <02cb01c7c84e$0d5d4890$802ca8c0@XPWork> References: <02cb01c7c84e$0d5d4890$802ca8c0@XPWork> Message-ID: <469CD317.3040904@sun.com> Try: cd control/make && make help for more help on the targets. -kto Ted Neward wrote: > WHEE-HAAAA! Success! (At least, so far--it's still going.) And yes, this is > with the implib32-created t2k.lib file that I manually dropped into the > binary plugs jre/bin directory. Sanity passed, and I'm assuming the rest of > the build will work. > > (Boy, will I look stupid if it doesn't work after all, but....) > > Next question: doing a 'make' builds a product build; how do I get a build > that defines all debug symbols? In other words, how do I get the various > hotspot-build options (debug/fastdebug/product and > core/compiler1/compiler2/tiered/etc) in the build? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >> bounces at openjdk.java.net] On Behalf Of Ted Neward >> Sent: Monday, July 16, 2007 6:04 PM >> To: Martin.Buchholz at Sun.COM >> Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM >> Subject: RE: State of the build on Windows? >> >> D'Oh! My bad, I suddenly re-read the error--I thought it was complaining >> about it NOT being set. Now your comment makes sense. Sorry. >> >> Ted Neward >> Java, .NET, XML Services >> Consulting, Teaching, Speaking, Writing >> http://www.tedneward.com >> >> >>> -----Original Message----- >>> From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] >>> Sent: Monday, July 16, 2007 5:57 PM >>> To: Ted Neward >>> Cc: build-dev at openjdk.java.net; Kelly.Ohair at Sun.COM >>> Subject: Re: State of the build on Windows? >>> >>> >>> >>> Ted Neward wrote: >>>> I don't know if these are potential bugs, by the way, or just bad >>> settings >>>> on my machine, but.... >>>> (*) JAVA_HOME is set by CMD.exe before invoking bash (as part of a >> .bat >>> file >>>> I created on my machine). Should it be getting it from the Windows >>>> environment (is it getting reset somehow in the jdk_generic_profile >>> shell >>>> script), and if not, should I set it myself again in >> jdk_generic_profile >>> or >>>> something? >>> I believe we strongly discourage setting the JAVA_HOME >>> environment variable, at least for JDK developers. >>> >>> Martin >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: >> 7/15/2007 >>> 2:21 PM >>> >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 >> 2:21 PM >> >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 >> 2:21 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 > 2:21 PM > > From ted at tedneward.com Tue Jul 17 09:06:45 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 17 Jul 2007 02:06:45 -0700 Subject: Errors in windows build? Message-ID: <02d601c7c851$ceadeec0$802ca8c0@XPWork> Got some strange errors in what I think are some generated .java files: C:/Prg/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J-client -J-Xmx383m -J-Xms1 28m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -target 5 -classpath c:/Prg/openjd k/openjdk/control/build/WINDOW~1/classes -bootclasspath c:/Prg/openjdk/openjdk/c ontrol/build/WINDOW~1/lib/jce.jar -sourcepath c:/Prg/openjdk/openjdk/control/bui ld/WINDOW~1/gensrc;../../../src/windows/classes;../../../src/share/classes -d c: /Prg/openjdk/openjdk/control/build/WINDOW~1/classes -encoding ascii -source 1.5 @c:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/java/java.lang/java/.clas ses. list c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:55: unclosed string literal " ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:355: ';' expected be_BY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:357: ';' expected bg_BG ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:359: ';' expected ca_ES ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:361: ';' expected cs_CZ ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:363: ';' expected da_DK ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:365: ';' expected de_AT ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:367: ';' expected de_DE ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:369: ';' expected el ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:371: ';' expected el_GR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:373: ';' expected en_AU ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:375: ';' expected en_GB ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:377: ';' expected en_IN ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:379: ';' expected en_NZ ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:381: ';' expected en_SG ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:383: ';' expected en_ZA ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:385: ';' expected es_AR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:387: ';' expected es_CL ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:389: ';' expected es_CR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:391: ';' expected es_EC ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:393: ';' expected es_GT ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:395: ';' expected es_MX ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:397: ';' expected es_PA ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:399: ';' expected es_PR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:401: ';' expected es_SV ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:403: ';' expected es_UY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:405: ';' expected et ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:407: ';' expected fi ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:409: ';' expected fr ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:411: ';' expected fr_CA ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:413: ';' expected fr_FR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:415: ';' expected ga ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:417: ';' expected hr ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:419: ';' expected hu ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:421: ';' expected in ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:423: ';' expected is ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:425: ';' expected it ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:427: ';' expected it_IT ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:429: ';' expected lt_LT ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:431: ';' expected lv_LV ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:433: ';' expected mk_MK ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:435: ';' expected ms_MY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:437: ';' expected mt_MT ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:439: ';' expected nl_BE ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:441: ';' expected no ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:443: ';' expected no_NO_NY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:445: ';' expected pl_PL ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:447: ';' expected pt_BR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:449: ';' expected ro ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:451: ';' expected ru ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:453: ';' expected sk ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:455: ';' expected sl ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:457: ';' expected sq ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:459: ';' expected sr ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:461: ';' expected sr_CS ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:463: ';' expected sr_RS ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:465: ';' expected sv_SE ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:467: ';' expected tr_TR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:469: ';' expected uk_UA ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:536: ';' expected ar_AE ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:538: ';' expected ar_DZ ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:540: ';' expected ar_IQ ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:542: ';' expected ar_KW ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:544: ';' expected ar_LY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:546: ';' expected ar_OM ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:548: ';' expected ar_SA ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:550: ';' expected ar_SY ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:552: ';' expected ar_YE ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:554: ';' expected iw ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:556: ';' expected ja ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:558: ';' expected ja_JP_JP ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:560: ';' expected ko_KR ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:562: ';' expected th_TH ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:564: ';' expected vi ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:566: ';' expected zh ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:568: ';' expected zh_HK ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:571: unclosed string literal "); ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:574: unclosed string literal " ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:958: ';' expected bg ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:960: ';' expected cs ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:962: ';' expected de ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:964: ';' expected en ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:966: ';' expected et ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:968: ';' expected fr ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:970: ';' expected hu ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:972: ';' expected it ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:974: ';' expected lv ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:976: ';' expected nl ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:978: ';' expected pl ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:980: ';' expected ro ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:982: ';' expected sk ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:984: ';' expected sq ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:986: ';' expected sv ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:988: ';' expected uk ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1081: ';' expected hi ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1083: ';' expected ja ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1085: ';' expected th ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1087: ';' expected zh ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1090: unclosed string literal "); ^ c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMeta Info .java:1093: unclosed string literal " ^ 100 errors make[3]: *** [.compile.classlist] Error 1 make[3]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make/java/java' make[2]: *** [all] Error 1 make[2]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make/java' make[1]: *** [all] Error 1 make[1]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' make: *** [j2se-build] Error 2 CYGWIN:XPJAVA:Ted[468] Any suggestions on how to fix these would be great? I don?t know if this is a general bug, a Windows-only bug, or just a source-tip issue. The build obviously got fairly far before reaching this point, so I?d love to get a complete build done just to prove it can be done on my box. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: 7/15/2007 2:21 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at tedneward.com Tue Jul 17 21:22:40 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 17 Jul 2007 14:22:40 -0700 Subject: Got another error I don't quite understand... Message-ID: <043f01c7c8b8$9c7a8000$802ca8c0@XPWork> Somehow, in this one run of the build, it appears that the forward-slashes are being turned into back-slashes: make[4]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/java/awt' /usr/bin/mkdir -p c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/classes (cd c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/classes && /cygdrive/c/Prg/jd k1.6.0/bin/jar xvf /cygdrive/c/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/jre/lib/rt.jar j ava/awt/color/CMMException.class java/awt/color/ColorSpace.class java/awt/color/ ICC_ColorSpace.class java/awt/color/ICC_Profile\$1.class java/awt/color/ICC_Prof ile\$2.class java/awt/color/ICC_Profile\$3.class java/awt/color/ICC_Profile.clas s java/awt/color/ICC_ProfileGray.class java/awt/color/ICC_ProfileRGB.class java/ awt/image/BandedSampleModel.class java/awt/image/ColorConvertOp.class java/awt/i mage/ComponentSampleModel.class java/awt/image/DataBuffer\$1.class java/awt/imag e/DataBuffer.class java/awt/image/DataBufferByte.class java/awt/image/DataBuffer Int.class java/awt/image/DataBufferShort.class java/awt/image/DataBufferUShort.c lass java/awt/image/MultiPixelPackedSampleModel.class java/awt/image/Raster.clas s java/awt/image/RenderedImage.class java/awt/image/SampleModel.class java/awt/i mage/SinglePixelPackedSampleModel.class java/awt/image/WritableRaster.class java /awt/image/WritableRenderedImage.class java/awt/image/renderable/ContextualRende redImageFactory.class java/awt/image/renderable/ParameterBlock.class java/awt/im age/renderable/RenderableImage.class java/awt/image/renderable/RenderableImageOp .class java/awt/image/renderable/RenderableImageProducer.class java/awt/image/re nderable/RenderContext.class java/awt/image/renderable/RenderedImageFactory.clas s) | /usr/bin/sed -e "s/^extracted:/ASSEMBLY_EXCEPTION:/" java.io.FileNotFoundException: \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ lib\rt.jar (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileInputStream.(FileInputStream.java:66) at sun.tools.jar.Main.run(Main.java:205) at sun.tools.jar.Main.main(Main.java:1022) Notice that in the FileNotFoundException it reports ?\cygwin\c\Prg\OpenJDK\...?, using backslashes instead of forward-slashes. Not being any kind of Cygwin expert (or even journeyman), I?m not sure if this is just how Java is reporting the exception (which I doubt), or if there is some kind of translator that kicked in there to reverse them, or what. The file does exist at that location, honest. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: 7/16/2007 5:42 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at sumatra.nl Wed Jul 18 04:46:29 2007 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 18 Jul 2007 06:46:29 +0200 Subject: Got another error I don't quite understand... In-Reply-To: <043f01c7c8b8$9c7a8000$802ca8c0@XPWork> References: <043f01c7c8b8$9c7a8000$802ca8c0@XPWork> Message-ID: Ted Neward wrote: > Somehow, in this one run of the build, it appears that the forward- > slashes are being turned into back-slashes: [...] > java.io.FileNotFoundException: > \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ [...] > Notice that in the FileNotFoundException it reports > "\cygwin\c\Prg\OpenJDK\...", using backslashes instead of forward- > slashes. Not being any kind of Cygwin expert (or even journeyman), I'm > not sure if this is just how Java is reporting the exception (which I > doubt), or if there is some kind of translator that kicked in there to > reverse them, or what. The file does exist at that location, honest. > :-) I got this message too. I think it is caused by one of your BLAH_BLAH_WHATEVER paths being "incorrect". I too set them to /cygdrive/c/.../, but given this error, I'm assuming that you must set them to C:\...\. Remember that when java.exe runs, it runs in Win32, so it doesn't understand the cygwin paths. Like you, I don't know very much about cygwin, so I also don't understand what happens if you pass a path on the command line or in the environment in cygwin (to a Win32 executable). FWIW, I gave up trying to build on Windows for the time being (I'm hoping to let you do the hard work ;-)). It's really quite depressing how feeble the build process is on Windows. It took me only a few minutes to get it to build on Ubuntu (and I'm a Windows person). Regards, Jeroen From ted at tedneward.com Wed Jul 18 09:37:34 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 18 Jul 2007 02:37:34 -0700 Subject: Got another error I don't quite understand... In-Reply-To: Message-ID: <05bb01c7c91f$47f70a50$802ca8c0@XPWork> The odd thing is, it goes for quite a while before it hits this error; intuition tells me if my paths were incorrect, this should have been picked up long before this point in the build. Plus, "make sanity" returns everything OK. If it passes the "sanity" check, I would assume (!) that the paths are OK. And FWIW, a quick check again reveals that they're all in the "/cygwin/c/..." format that the build scripts seem to demand; if the Java tools need the traditional Win32 format (which I can believe), then perhaps the build script needs to flip them back to C:\ format before processing? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Jeroen Frijters [mailto:jeroen at sumatra.nl] > Sent: Tuesday, July 17, 2007 9:46 PM > To: Ted Neward; build-dev at openjdk.java.net > Subject: RE: Got another error I don't quite understand... > > Ted Neward wrote: > > Somehow, in this one run of the build, it appears that the forward- > > slashes are being turned into back-slashes: > [...] > > java.io.FileNotFoundException: > > \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ > [...] > > Notice that in the FileNotFoundException it reports > > "\cygwin\c\Prg\OpenJDK\...", using backslashes instead of forward- > > slashes. Not being any kind of Cygwin expert (or even journeyman), I'm > > not sure if this is just how Java is reporting the exception (which I > > doubt), or if there is some kind of translator that kicked in there to > > reverse them, or what. The file does exist at that location, honest. > > :-) > > I got this message too. I think it is caused by one of your > BLAH_BLAH_WHATEVER paths being "incorrect". I too set them to > /cygdrive/c/.../, but given this error, I'm assuming that you must set > them to C:\...\. > > Remember that when java.exe runs, it runs in Win32, so it doesn't > understand the cygwin paths. Like you, I don't know very much about > cygwin, so I also don't understand what happens if you pass a path on the > command line or in the environment in cygwin (to a Win32 executable). > > FWIW, I gave up trying to build on Windows for the time being (I'm hoping > to let you do the hard work ;-)). It's really quite depressing how feeble > the build process is on Windows. It took me only a few minutes to get it > to build on Ubuntu (and I'm a Windows person). > > Regards, > Jeroen > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: 7/16/2007 > 5:42 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: 7/16/2007 5:42 PM From Kelly.Ohair at Sun.COM Wed Jul 18 17:41:04 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 18 Jul 2007 10:41:04 -0700 Subject: Errors in windows build? In-Reply-To: <02d601c7c851$ceadeec0$802ca8c0@XPWork> References: <02d601c7c851$ceadeec0$802ca8c0@XPWork> Message-ID: <469E50B0.3080605@sun.com> There are some places in the build where source files are generated, these will land in the 'gensrc' directory. Some of these generated sources are created with rather old shell scripts that when they fail, the shell scripts sometimes don't terminate the Make process, or make fails and leaves output files around that have garbage in them. The second 'make' then thinks the files are already generated and trys to compile them. Try a 'make clean' and see if it repeats. If it repeats, then I suspect that there is something wrong with the generation of these source files. -kto Ted Neward wrote: > Got some strange errors in what I think are some generated .java files: > > > > C:/Prg/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J-client -J-Xmx383m > -J-Xms1 > > 28m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -target 5 -classpath > c:/Prg/openjd > > k/openjdk/control/build/WINDOW~1/classes -bootclasspath > c:/Prg/openjdk/openjdk/c > > ontrol/build/WINDOW~1/lib/jce.jar -sourcepath > c:/Prg/openjdk/openjdk/control/bui > > ld/WINDOW~1/gensrc;../../../src/windows/classes;../../../src/share/classes > -d c: > > /Prg/openjdk/openjdk/control/build/WINDOW~1/classes -encoding ascii > -source 1.5 > > @c:/Prg/openjdk/openjdk/control/build/WINDOW~1/tmp/java/java.lang/java/.classes. > > list > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:55: unclosed string literal > > " > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:355: ';' expected > > be_BY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:357: ';' expected > > bg_BG > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:359: ';' expected > > ca_ES > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:361: ';' expected > > cs_CZ > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:363: ';' expected > > da_DK > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:365: ';' expected > > de_AT > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:367: ';' expected > > de_DE > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:369: ';' expected > > el > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:371: ';' expected > > el_GR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:373: ';' expected > > en_AU > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:375: ';' expected > > en_GB > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:377: ';' expected > > en_IN > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:379: ';' expected > > en_NZ > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:381: ';' expected > > en_SG > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:383: ';' expected > > en_ZA > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:385: ';' expected > > es_AR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:387: ';' expected > > es_CL > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:389: ';' expected > > es_CR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:391: ';' expected > > es_EC > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:393: ';' expected > > es_GT > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:395: ';' expected > > es_MX > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:397: ';' expected > > es_PA > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:399: ';' expected > > es_PR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:401: ';' expected > > es_SV > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:403: ';' expected > > es_UY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:405: ';' expected > > et > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:407: ';' expected > > fi > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:409: ';' expected > > fr > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:411: ';' expected > > fr_CA > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:413: ';' expected > > fr_FR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:415: ';' expected > > ga > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:417: ';' expected > > hr > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:419: ';' expected > > hu > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:421: ';' expected > > in > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:423: ';' expected > > is > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:425: ';' expected > > it > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:427: ';' expected > > it_IT > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:429: ';' expected > > lt_LT > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:431: ';' expected > > lv_LV > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:433: ';' expected > > mk_MK > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:435: ';' expected > > ms_MY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:437: ';' expected > > mt_MT > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:439: ';' expected > > nl_BE > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:441: ';' expected > > no > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:443: ';' expected > > no_NO_NY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:445: ';' expected > > pl_PL > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:447: ';' expected > > pt_BR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:449: ';' expected > > ro > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:451: ';' expected > > ru > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:453: ';' expected > > sk > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:455: ';' expected > > sl > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:457: ';' expected > > sq > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:459: ';' expected > > sr > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:461: ';' expected > > sr_CS > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:463: ';' expected > > sr_RS > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:465: ';' expected > > sv_SE > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:467: ';' expected > > tr_TR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:469: ';' expected > > uk_UA > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:536: ';' expected > > ar_AE > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:538: ';' expected > > ar_DZ > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:540: ';' expected > > ar_IQ > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:542: ';' expected > > ar_KW > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:544: ';' expected > > ar_LY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:546: ';' expected > > ar_OM > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:548: ';' expected > > ar_SA > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:550: ';' expected > > ar_SY > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:552: ';' expected > > ar_YE > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:554: ';' expected > > iw > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:556: ';' expected > > ja > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:558: ';' expected > > ja_JP_JP > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:560: ';' expected > > ko_KR > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:562: ';' expected > > th_TH > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:564: ';' expected > > vi > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:566: ';' expected > > zh > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:568: ';' expected > > zh_HK > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:571: unclosed string literal > > "); > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:574: unclosed string literal > > " > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:958: ';' expected > > bg > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:960: ';' expected > > cs > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:962: ';' expected > > de > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:964: ';' expected > > en > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:966: ';' expected > > et > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:968: ';' expected > > fr > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:970: ';' expected > > hu > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:972: ';' expected > > it > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:974: ';' expected > > lv > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:976: ';' expected > > nl > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:978: ';' expected > > pl > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:980: ';' expected > > ro > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:982: ';' expected > > sk > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:984: ';' expected > > sq > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:986: ';' expected > > sv > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:988: ';' expected > > uk > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1081: ';' expected > > hi > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1083: ';' expected > > ja > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1085: ';' expected > > th > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1087: ';' expected > > zh > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1090: unclosed string literal > > "); > > ^ > > c:\Prg\openjdk\openjdk\control\build\WINDOW~1\gensrc\sun\util\LocaleDataMetaInfo > > .java:1093: unclosed string literal > > " > > ^ > > 100 errors > > make[3]: *** [.compile.classlist] Error 1 > > make[3]: Leaving directory > `/cygdrive/c/Prg/openjdk/openjdk/j2se/make/java/java' > > > > make[2]: *** [all] Error 1 > > make[2]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make/java' > > make[1]: *** [all] Error 1 > > make[1]: Leaving directory `/cygdrive/c/Prg/openjdk/openjdk/j2se/make' > > make: *** [j2se-build] Error 2 > > CYGWIN:XPJAVA:Ted[468] > > > > Any suggestions on how to fix these would be great? I don?t know if this > is a general bug, a Windows-only bug, or just a source-tip issue. > > > > The build obviously got fairly far before reaching this point, so I?d > love to get a complete build done just to prove it can be done on my > box. :-) > > > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.6/902 - Release Date: > 7/15/2007 2:21 PM > From Kelly.Ohair at Sun.COM Wed Jul 18 17:50:51 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 18 Jul 2007 10:50:51 -0700 Subject: Got another error I don't quite understand... In-Reply-To: <05bb01c7c91f$47f70a50$802ca8c0@XPWork> References: <05bb01c7c91f$47f70a50$802ca8c0@XPWork> Message-ID: <469E52FB.2000803@sun.com> Inside Sun we have used MKS (not cygwin) for a long long time, so there is quite a bit of history here. In general, you need to try and use paths in what is called the "mixed" format of drive letters and the '/' character, e.g. C:/ paths. It's extremely rare that a Windows utility you need will not accept the C:/ style of pathnames (NMAKE is the only one I know about). In general shells like sh, bash, ksh, csh, tcsh, etc. treat the \ character as an escape character and they often disappear, so using the \ path in any path you give to GNU make via the command line or via environment variables is a often a bad idea. When you see things like "C:\\\\path\\\\dir" in shell scripts, they are trying to get around this \ problem by escaping the \ character, gets real ugly because it's hard to know how many passes the shell might make over a string. The cygwin paths look like /cygdrive/c/ and these aren't good to use either because most Windows tools including java.exe don't understand this path syntax. But the trick with CYGWIN is that the PATH variable MUST use the /cygdrive/ form because they use the ':' character as a path separator. The various tools spit out various path formats, I'd ignore that. Make sure all the paths you supply to GNU make and put in the ALT_* variables are the C:/ style path names. -kto Ted Neward wrote: > The odd thing is, it goes for quite a while before it hits this error; > intuition tells me if my paths were incorrect, this should have been picked > up long before this point in the build. > > Plus, "make sanity" returns everything OK. If it passes the "sanity" check, > I would assume (!) that the paths are OK. > > And FWIW, a quick check again reveals that they're all in the > "/cygwin/c/..." format that the build scripts seem to demand; if the Java > tools need the traditional Win32 format (which I can believe), then perhaps > the build script needs to flip them back to C:\ format before processing? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: Jeroen Frijters [mailto:jeroen at sumatra.nl] >> Sent: Tuesday, July 17, 2007 9:46 PM >> To: Ted Neward; build-dev at openjdk.java.net >> Subject: RE: Got another error I don't quite understand... >> >> Ted Neward wrote: >>> Somehow, in this one run of the build, it appears that the forward- >>> slashes are being turned into back-slashes: >> [...] >>> java.io.FileNotFoundException: >>> \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ >> [...] >>> Notice that in the FileNotFoundException it reports >>> "\cygwin\c\Prg\OpenJDK\...", using backslashes instead of forward- >>> slashes. Not being any kind of Cygwin expert (or even journeyman), I'm >>> not sure if this is just how Java is reporting the exception (which I >>> doubt), or if there is some kind of translator that kicked in there to >>> reverse them, or what. The file does exist at that location, honest. >>> :-) >> I got this message too. I think it is caused by one of your >> BLAH_BLAH_WHATEVER paths being "incorrect". I too set them to >> /cygdrive/c/.../, but given this error, I'm assuming that you must set >> them to C:\...\. >> >> Remember that when java.exe runs, it runs in Win32, so it doesn't >> understand the cygwin paths. Like you, I don't know very much about >> cygwin, so I also don't understand what happens if you pass a path on the >> command line or in the environment in cygwin (to a Win32 executable). >> >> FWIW, I gave up trying to build on Windows for the time being (I'm hoping >> to let you do the hard work ;-)). It's really quite depressing how feeble >> the build process is on Windows. It took me only a few minutes to get it >> to build on Ubuntu (and I'm a Windows person). >> >> Regards, >> Jeroen >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: 7/16/2007 >> 5:42 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: 7/16/2007 > 5:42 PM > > From dan at fabulich.com Wed Jul 18 23:10:06 2007 From: dan at fabulich.com (Dan Fabulich) Date: Wed, 18 Jul 2007 16:10:06 -0700 (Pacific Daylight Time) Subject: Errors in windows build? In-Reply-To: <469E50B0.3080605@sun.com> References: <02d601c7c851$ceadeec0$802ca8c0@XPWork> <469E50B0.3080605@sun.com> Message-ID: Thanks for your remarks, Kelly. I'd like to make a remark/request here. It's clear that the Windows OpenJDK build didn't go through any QA, in light of the fact that it can't possibly succeed without t2k.lib. In light of that, I'd say that there's no reason to assume that the rest of the build works as documented, either. There could well be bugs in the build scripts or in the documentation that make it impossible to complete the build. Would it be possible for someone at Sun (ideally a QA engineer) to grab a copy of the real binary plugs, add a copy of t2k.lib in the appropriate directory and then build OpenJDK following the directions from the README, (using Cygwin rather than MKS, etc.)? What I'm looking for is for someone at Sun to say "works for me!" Nobody's said that yet in any e-mail that I can find, and that worries me. -Dan From ted at tedneward.com Thu Jul 19 02:33:21 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 18 Jul 2007 19:33:21 -0700 Subject: Got another error I don't quite understand... In-Reply-To: <469E52FB.2000803@sun.com> Message-ID: <080d01c7c9ad$2e446d30$802ca8c0@XPWork> I'll flip them over and try again. So, just to make sure I understand correctly, all the ALT_* paths should use C-colon-forwardslash syntax, yes? Even though we're launching from inside a Cygwin shell? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Wednesday, July 18, 2007 10:51 AM > To: Ted Neward > Cc: 'Jeroen Frijters'; build-dev at openjdk.java.net > Subject: Re: Got another error I don't quite understand... > > > Inside Sun we have used MKS (not cygwin) for a long long time, so > there is quite a bit of history here. > > In general, you need to try and use paths in what is called the > "mixed" format of drive letters and the '/' character, e.g. C:/ > paths. It's extremely rare that a Windows utility you need will not accept > the C:/ style of pathnames (NMAKE is the only one I know about). > > In general shells like sh, bash, ksh, csh, tcsh, etc. treat the \ > character as an escape character and they often disappear, so using > the \ path in any path you give to GNU make via the command line or > via environment variables is a often a bad idea. When you see things > like "C:\\\\path\\\\dir" in shell scripts, they are trying to get around > this \ problem by escaping the \ character, gets real ugly because it's > hard > to know how many passes the shell might make over a string. > > The cygwin paths look like /cygdrive/c/ and these aren't good to use > either because most Windows tools including java.exe don't understand > this path syntax. But the trick with CYGWIN is that the PATH variable > MUST use the /cygdrive/ form because they use the ':' character as a > path separator. > > The various tools spit out various path formats, I'd ignore that. > > Make sure all the paths you supply to GNU make and put in the ALT_* > variables are the C:/ style path names. > > -kto > > > Ted Neward wrote: > > The odd thing is, it goes for quite a while before it hits this error; > > intuition tells me if my paths were incorrect, this should have been > picked > > up long before this point in the build. > > > > Plus, "make sanity" returns everything OK. If it passes the "sanity" > check, > > I would assume (!) that the paths are OK. > > > > And FWIW, a quick check again reveals that they're all in the > > "/cygwin/c/..." format that the build scripts seem to demand; if the > Java > > tools need the traditional Win32 format (which I can believe), then > perhaps > > the build script needs to flip them back to C:\ format before > processing? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: Jeroen Frijters [mailto:jeroen at sumatra.nl] > >> Sent: Tuesday, July 17, 2007 9:46 PM > >> To: Ted Neward; build-dev at openjdk.java.net > >> Subject: RE: Got another error I don't quite understand... > >> > >> Ted Neward wrote: > >>> Somehow, in this one run of the build, it appears that the forward- > >>> slashes are being turned into back-slashes: > >> [...] > >>> java.io.FileNotFoundException: > >>> \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ > >> [...] > >>> Notice that in the FileNotFoundException it reports > >>> "\cygwin\c\Prg\OpenJDK\...", using backslashes instead of forward- > >>> slashes. Not being any kind of Cygwin expert (or even journeyman), I'm > >>> not sure if this is just how Java is reporting the exception (which I > >>> doubt), or if there is some kind of translator that kicked in there to > >>> reverse them, or what. The file does exist at that location, honest. > >>> :-) > >> I got this message too. I think it is caused by one of your > >> BLAH_BLAH_WHATEVER paths being "incorrect". I too set them to > >> /cygdrive/c/.../, but given this error, I'm assuming that you must set > >> them to C:\...\. > >> > >> Remember that when java.exe runs, it runs in Win32, so it doesn't > >> understand the cygwin paths. Like you, I don't know very much about > >> cygwin, so I also don't understand what happens if you pass a path on > the > >> command line or in the environment in cygwin (to a Win32 executable). > >> > >> FWIW, I gave up trying to build on Windows for the time being (I'm > hoping > >> to let you do the hard work ;-)). It's really quite depressing how > feeble > >> the build process is on Windows. It took me only a few minutes to get > it > >> to build on Ubuntu (and I'm a Windows person). > >> > >> Regards, > >> Jeroen > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: > 7/16/2007 > >> 5:42 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: > 7/16/2007 > > 5:42 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 > 6:30 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM From Kelly.Ohair at Sun.COM Thu Jul 19 02:36:01 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 18 Jul 2007 19:36:01 -0700 Subject: Got another error I don't quite understand... In-Reply-To: <080d01c7c9ad$2e446d30$802ca8c0@XPWork> References: <080d01c7c9ad$2e446d30$802ca8c0@XPWork> Message-ID: <469ECE11.5050306@sun.com> Ted Neward wrote: > I'll flip them over and try again. So, just to make sure I understand > correctly, all the ALT_* paths should use C-colon-forwardslash syntax, yes? > Even though we're launching from inside a Cygwin shell? Yes. -kto > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Wednesday, July 18, 2007 10:51 AM >> To: Ted Neward >> Cc: 'Jeroen Frijters'; build-dev at openjdk.java.net >> Subject: Re: Got another error I don't quite understand... >> >> >> Inside Sun we have used MKS (not cygwin) for a long long time, so >> there is quite a bit of history here. >> >> In general, you need to try and use paths in what is called the >> "mixed" format of drive letters and the '/' character, e.g. C:/ >> paths. It's extremely rare that a Windows utility you need will not accept >> the C:/ style of pathnames (NMAKE is the only one I know about). >> >> In general shells like sh, bash, ksh, csh, tcsh, etc. treat the \ >> character as an escape character and they often disappear, so using >> the \ path in any path you give to GNU make via the command line or >> via environment variables is a often a bad idea. When you see things >> like "C:\\\\path\\\\dir" in shell scripts, they are trying to get around >> this \ problem by escaping the \ character, gets real ugly because it's >> hard >> to know how many passes the shell might make over a string. >> >> The cygwin paths look like /cygdrive/c/ and these aren't good to use >> either because most Windows tools including java.exe don't understand >> this path syntax. But the trick with CYGWIN is that the PATH variable >> MUST use the /cygdrive/ form because they use the ':' character as a >> path separator. >> >> The various tools spit out various path formats, I'd ignore that. >> >> Make sure all the paths you supply to GNU make and put in the ALT_* >> variables are the C:/ style path names. >> >> -kto >> >> >> Ted Neward wrote: >>> The odd thing is, it goes for quite a while before it hits this error; >>> intuition tells me if my paths were incorrect, this should have been >> picked >>> up long before this point in the build. >>> >>> Plus, "make sanity" returns everything OK. If it passes the "sanity" >> check, >>> I would assume (!) that the paths are OK. >>> >>> And FWIW, a quick check again reveals that they're all in the >>> "/cygwin/c/..." format that the build scripts seem to demand; if the >> Java >>> tools need the traditional Win32 format (which I can believe), then >> perhaps >>> the build script needs to flip them back to C:\ format before >> processing? >>> Ted Neward >>> Java, .NET, XML Services >>> Consulting, Teaching, Speaking, Writing >>> http://www.tedneward.com >>> >>> >>>> -----Original Message----- >>>> From: Jeroen Frijters [mailto:jeroen at sumatra.nl] >>>> Sent: Tuesday, July 17, 2007 9:46 PM >>>> To: Ted Neward; build-dev at openjdk.java.net >>>> Subject: RE: Got another error I don't quite understand... >>>> >>>> Ted Neward wrote: >>>>> Somehow, in this one run of the build, it appears that the forward- >>>>> slashes are being turned into back-slashes: >>>> [...] >>>>> java.io.FileNotFoundException: >>>>> \cygdrive\c\Prg\OpenJDK\BinaryPlugs\jdk1.7.0\jre\ >>>> [...] >>>>> Notice that in the FileNotFoundException it reports >>>>> "\cygwin\c\Prg\OpenJDK\...", using backslashes instead of forward- >>>>> slashes. Not being any kind of Cygwin expert (or even journeyman), I'm >>>>> not sure if this is just how Java is reporting the exception (which I >>>>> doubt), or if there is some kind of translator that kicked in there to >>>>> reverse them, or what. The file does exist at that location, honest. >>>>> :-) >>>> I got this message too. I think it is caused by one of your >>>> BLAH_BLAH_WHATEVER paths being "incorrect". I too set them to >>>> /cygdrive/c/.../, but given this error, I'm assuming that you must set >>>> them to C:\...\. >>>> >>>> Remember that when java.exe runs, it runs in Win32, so it doesn't >>>> understand the cygwin paths. Like you, I don't know very much about >>>> cygwin, so I also don't understand what happens if you pass a path on >> the >>>> command line or in the environment in cygwin (to a Win32 executable). >>>> >>>> FWIW, I gave up trying to build on Windows for the time being (I'm >> hoping >>>> to let you do the hard work ;-)). It's really quite depressing how >> feeble >>>> the build process is on Windows. It took me only a few minutes to get >> it >>>> to build on Ubuntu (and I'm a Windows person). >>>> >>>> Regards, >>>> Jeroen >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: >> 7/16/2007 >>>> 5:42 PM >>>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.8/904 - Release Date: >> 7/16/2007 >>> 5:42 PM >>> >>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 >> 6:30 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 > 6:30 PM > > From Kelly.Ohair at Sun.COM Thu Jul 19 02:51:01 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 18 Jul 2007 19:51:01 -0700 Subject: Errors in windows build? In-Reply-To: References: <02d601c7c851$ceadeec0$802ca8c0@XPWork> <469E50B0.3080605@sun.com> Message-ID: <469ED195.5030406@sun.com> It's been my experience that it's almost impossible to say for sure that all Windows users will be able to build. All we can say is that in one particular case, we know it builds. There are just too many variations with a Windows system's configuration and all the versions of CYGWIN PSDK OS etc. Normally we nail down our Windows build systems once we get them configured and working. Linux and Solaris is much easier to deal with. But I think I understand what you are after, so I will try a build myself once we have the windows binary plugs created. Give me a few days. I'm not exactly sure what the QA procedures are, but we explicitly ruled out any QA Windows OpenJDK build testing initially. The fact that the VS003 compiler on Windows has to be purchased makes it difficult for the QA testing, normally QA people don't have to "compile" anything. ;^) Someday soon we can get it going with the free VS2005 compilers, but for now you really need VS2003. -kto Dan Fabulich wrote: > > Thanks for your remarks, Kelly. > > I'd like to make a remark/request here. It's clear that the Windows > OpenJDK build didn't go through any QA, in light of the fact that it > can't possibly succeed without t2k.lib. In light of that, I'd say that > there's no reason to assume that the rest of the build works as > documented, either. There could well be bugs in the build scripts or in > the documentation that make it impossible to complete the build. > > Would it be possible for someone at Sun (ideally a QA engineer) to grab > a copy of the real binary plugs, add a copy of t2k.lib in the > appropriate directory and then build OpenJDK following the directions > from the README, (using Cygwin rather than MKS, etc.)? > > What I'm looking for is for someone at Sun to say "works for me!" > Nobody's said that yet in any e-mail that I can find, and that worries me. > > -Dan From ted at tedneward.com Thu Jul 19 05:13:49 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 18 Jul 2007 22:13:49 -0700 Subject: Errors in windows build? In-Reply-To: <469ED195.5030406@sun.com> Message-ID: <084f01c7c9c3$98672250$802ca8c0@XPWork> True, but as Dan points out, just knowing that "somebody" (even if it's just one person) can build it helps build confidence immeasurably. Meanwhile, has anyone tried to build it with just the Platform SDK? If I'm not mistaken (which I could be), I think there's a C++ compiler that comes with it. If nothing else, it plus the VC++ Express install should be everything that VC++ has in 2003... (modulo any 2003-vs-2005 language warnings/differences, of course...) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Wednesday, July 18, 2007 7:51 PM > To: Dan Fabulich > Cc: Ted Neward; build-dev at openjdk.java.net > Subject: Re: Errors in windows build? > > > It's been my experience that it's almost impossible to say for sure that > all Windows users will be able to build. > All we can say is that in one particular case, we know it builds. > There are just too many variations with a Windows system's configuration > and all the versions of CYGWIN PSDK OS etc. > Normally we nail down our Windows build systems once we get them > configured and working. Linux and Solaris is much easier to deal with. > > But I think I understand what you are after, so I will try a build myself > once we have the windows binary plugs created. > Give me a few days. > > I'm not exactly sure what the QA procedures are, but we explicitly > ruled out any QA Windows OpenJDK build testing initially. > The fact that the VS003 compiler on Windows has to be purchased > makes it difficult for the QA testing, normally QA people don't have to > "compile" anything. ;^) > Someday soon we can get it going with the free VS2005 compilers, but for > now you really need VS2003. > > -kto > > Dan Fabulich wrote: > > > > Thanks for your remarks, Kelly. > > > > I'd like to make a remark/request here. It's clear that the Windows > > OpenJDK build didn't go through any QA, in light of the fact that it > > can't possibly succeed without t2k.lib. In light of that, I'd say that > > there's no reason to assume that the rest of the build works as > > documented, either. There could well be bugs in the build scripts or in > > the documentation that make it impossible to complete the build. > > > > Would it be possible for someone at Sun (ideally a QA engineer) to grab > > a copy of the real binary plugs, add a copy of t2k.lib in the > > appropriate directory and then build OpenJDK following the directions > > from the README, (using Cygwin rather than MKS, etc.)? > > > > What I'm looking for is for someone at Sun to say "works for me!" > > Nobody's said that yet in any e-mail that I can find, and that worries > me. > > > > -Dan > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 > 6:30 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM From ted at tedneward.com Thu Jul 19 08:49:44 2007 From: ted at tedneward.com (Ted Neward) Date: Thu, 19 Jul 2007 01:49:44 -0700 Subject: T2K needed in Linux, also? Message-ID: <088f01c7c9e1$c363a320$802ca8c0@XPWork> When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a build error saying libt2k.so cannot be found. Am I missing something? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 6:30 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Phil.Race at Sun.COM Thu Jul 19 12:52:10 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 19 Jul 2007 05:52:10 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <088f01c7c9e1$c363a320$802ca8c0@XPWork> References: <088f01c7c9e1$c363a320$802ca8c0@XPWork> Message-ID: <469F5E7A.2070504@sun.com> Ted Neward wrote: > > When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > build error saying libt2k.so cannot be found. Am I missing something? > Yes, sounds like you are missing the entire binary plug download, or haven't properly pointed to it's location. -phil. > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > 7/17/2007 6:30 PM > From ted at tedneward.com Thu Jul 19 17:10:26 2007 From: ted at tedneward.com (Ted Neward) Date: Thu, 19 Jul 2007 10:10:26 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <469F5E7A.2070504@sun.com> Message-ID: <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> Yep, had it pointing to the Import JDK (1.6) instead of the binary plug JDK (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) By the way, in case those on this list haven't seen it, the build on Intel machines won't work, as there's a compilation error in a source file, as reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: #### --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 10:29:14.412986944 -0700 +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 10:29:31.499389416 -0700 @@ -158,7 +158,7 @@ // Easily misused constructor make them private #ifndef _LP64 - Address::Address(address loc, RelocationHolder spec); + Address(address loc, RelocationHolder spec); #endif // _LP64 public: #### Peter Kessler reported it as already reported, a la http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html but no official bug had been filed, and there was some concern about Sunil's contributor status or whatnot. Not sure what happened to it from there. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > Sent: Thursday, July 19, 2007 5:52 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: T2K needed in Linux, also? > > Ted Neward wrote: > > > > When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > > build error saying libt2k.so cannot be found. Am I missing something? > > > > Yes, sounds like you are missing the entire binary plug download, or > haven't properly pointed to it's location. > > -phil. > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > > 7/17/2007 6:30 PM > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 > 6:30 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007 3:30 PM From Kelly.Ohair at Sun.COM Thu Jul 19 17:14:10 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 19 Jul 2007 10:14:10 -0700 Subject: Errors in windows build? In-Reply-To: <084f01c7c9c3$98672250$802ca8c0@XPWork> References: <084f01c7c9c3$98672250$802ca8c0@XPWork> Message-ID: <469F9BE2.1090902@sun.com> Changing C/C++ compilers should be an easy thing to do, but it is not. Even if you get it so that it "builds", that doesn't mean much. The Hotspot VM is also a compiler, and generates native code, and that code will connect to or get run with the C/C++ generated code at some point. Minor tweaks to the C/C++ optimized code can collide with optimizations done in the Hotspot generated code sometimes, register usage assumptions etc. Sometimes it's our fault, sometimes it's poor specs, sometimes it's bugs in the C/C++ compiler and we have to disable optimizations on certain source files. Some of these nastier problems take Hotspot VM experts to track down. And even after you think it runs correctly, there is the performance benchmarks we have to check to verify we haven't regressed. It has gotten easier over the years, but it is still a trip through a potential mine field. Don't get me wrong, we need to upgrade compilers, and the free ones are ideal, and I've usually the one trying to get us moved to new compilers, but it's never fun to track down compiler errors, no matter whose they are. It's easy for any project to under-estimate changes to the build system. In the past, the Visual Studio (VS) compilers changed so much from release to release that it wasn't simple to transition to a new version, sometimes even a service pack could break things (this was true in VC6). Some of this was due to the C++ compiler conforming to the C++ standard, but some of it was the habit of the VS compilers to remove options, change options, or change the meaning of optimization options. I think things have stabilized around the C++ standard, all the platform compilers shared this issue to some degree. The Platform SDK compiler seems to be potluck, and if it does have a 32bit compiler in it, I kind of doubt it's complete, but I could be wrong. The current April 2005 Platform SDK we use on 64bit Windows behaves a little like a VS2005 product but isn't, so it's some kind of early VS2005 compiler as best as I can tell. We should change to the March 2006 version I suppose, but it took us many weeks to track down the problems that this April 2005 one forced out of the product. Years ago when we investigated the VS2003 free compiler, it was missing some key LIB files that we needed to build part of the jdk, LIB files only available with the purchased product. So we abandoned that effort. The VS2005 free version may be different, but I did hear that it didn't play well with the latest Platform SDK on 32bit Windows (you have to change something to get them to play together?). Keep in mind that we currently still build on and support Windows 2000, and ever time we upgrade compilers we have to make sure our overall support platform story still works. As we visit the list of official supported build and runtime platforms for JDK7, I'm not sure if Windows 2000 stays in the picture or not. Remains to be seen. From a developer point of view, I'd like to say "use what you want", but when it comes down to official builds, and which of the numerous combinations of OS, compilers, SDK's, etc. we can test build on, there are limitations. We need stability in our build systems to create stable products, so we can be downright paranoid when changing any official build components. Developers should have more flexibility, and can take more risks. We thought about picking some "common developer" configurations and maybe put some automated OpenJDK build/testing around those, maybe: * Solaris Express & Sun Studio 12 compilers * Linux Ubuntu & gcc 4 * Windows XP and VS2005 free compiler But we just aren't there yet, and Windows is low on the priority list. I hope this helps explain things, sorry about the long winded answer. -kto Ted Neward wrote: > True, but as Dan points out, just knowing that "somebody" (even if it's just > one person) can build it helps build confidence immeasurably. > > Meanwhile, has anyone tried to build it with just the Platform SDK? If I'm > not mistaken (which I could be), I think there's a C++ compiler that comes > with it. If nothing else, it plus the VC++ Express install should be > everything that VC++ has in 2003... (modulo any 2003-vs-2005 language > warnings/differences, of course...) > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Wednesday, July 18, 2007 7:51 PM >> To: Dan Fabulich >> Cc: Ted Neward; build-dev at openjdk.java.net >> Subject: Re: Errors in windows build? >> >> >> It's been my experience that it's almost impossible to say for sure that >> all Windows users will be able to build. >> All we can say is that in one particular case, we know it builds. >> There are just too many variations with a Windows system's configuration >> and all the versions of CYGWIN PSDK OS etc. >> Normally we nail down our Windows build systems once we get them >> configured and working. Linux and Solaris is much easier to deal with. >> >> But I think I understand what you are after, so I will try a build myself >> once we have the windows binary plugs created. >> Give me a few days. >> >> I'm not exactly sure what the QA procedures are, but we explicitly >> ruled out any QA Windows OpenJDK build testing initially. >> The fact that the VS003 compiler on Windows has to be purchased >> makes it difficult for the QA testing, normally QA people don't have to >> "compile" anything. ;^) >> Someday soon we can get it going with the free VS2005 compilers, but for >> now you really need VS2003. >> >> -kto >> >> Dan Fabulich wrote: >>> Thanks for your remarks, Kelly. >>> >>> I'd like to make a remark/request here. It's clear that the Windows >>> OpenJDK build didn't go through any QA, in light of the fact that it >>> can't possibly succeed without t2k.lib. In light of that, I'd say that >>> there's no reason to assume that the rest of the build works as >>> documented, either. There could well be bugs in the build scripts or in >>> the documentation that make it impossible to complete the build. >>> >>> Would it be possible for someone at Sun (ideally a QA engineer) to grab >>> a copy of the real binary plugs, add a copy of t2k.lib in the >>> appropriate directory and then build OpenJDK following the directions >>> from the README, (using Cygwin rather than MKS, etc.)? >>> >>> What I'm looking for is for someone at Sun to say "works for me!" >>> Nobody's said that yet in any e-mail that I can find, and that worries >> me. >>> -Dan >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 >> 6:30 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 7/17/2007 > 6:30 PM > > From Peter.Kessler at Sun.COM Thu Jul 19 18:03:15 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 19 Jul 2007 11:03:15 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> References: <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> Message-ID: <469FA763.1010504@Sun.COM> We (cough) independently discovered the compilation problem with assembler_i486.hpp and gcc4.1.2. It's bug #6578344, e.g., http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578344 and I can see it's fixed in our code base, so it will be published in the next drop. ... peter Ted Neward wrote: > Yep, had it pointing to the Import JDK (1.6) instead of the binary plug JDK > (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > > By the way, in case those on this list haven't seen it, the build on Intel > machines won't work, as there's a compilation error in a source file, as > reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > > #### > > --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > 10:29:14.412986944 -0700 > +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > 10:29:31.499389416 -0700 > @@ -158,7 +158,7 @@ > > // Easily misused constructor make them private #ifndef _LP64 > - Address::Address(address loc, RelocationHolder spec); > + Address(address loc, RelocationHolder spec); > #endif // _LP64 > > public: > > #### > > Peter Kessler reported it as already reported, a la > > http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > > but no official bug had been filed, and there was some concern about Sunil's > contributor status or whatnot. Not sure what happened to it from there. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com From freds at jfrog.org Thu Jul 19 18:39:02 2007 From: freds at jfrog.org (Frederic Simon) Date: Thu, 19 Jul 2007 21:39:02 +0300 Subject: T2K needed in Linux, also? In-Reply-To: <469FA763.1010504@Sun.COM> References: <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> <469FA763.1010504@Sun.COM> Message-ID: I got the same thing on hotspot/src/cpu/amd64/vm/assembler_amd64.hpp and I used a patch like described here Index: hotspot/src/cpu/amd64/vm/assembler_amd64.hpp =================================================================== --- hotspot/src/cpu/amd64/vm/assembler_amd64.hpp (revision 242) +++ hotspot/src/cpu/amd64/vm/assembler_amd64.hpp (working copy) @@ -153,8 +153,8 @@ RelocationHolder _rspec; // Easily misused constructors make them private - Address::Address(int disp, address loc, relocInfo::relocType rtype); - Address::Address(int disp, address loc, RelocationHolder spec); + Address(int disp, address loc, relocInfo::relocType rtype); + Address(int disp, address loc, RelocationHolder spec); public: // creation I compiled, modified and used b13 with no problem, b14 had the gc_parallel issue, and now b15 the Address issue. I don't complain at all, I just want a place where we can share the patches faster and easier. I think the OpenJDK should have an open Bug Database so we can create entry with patches (my 2cts). Now with b15 on my Ubuntu 7.04 64 bit Intel, I'm stuck with: # Running javac: /work/java.net/openjdk.orig/control/build/linux-amd64/bin/javac -J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -classpath /work/java.net/openjdk.orig/control/build/linux-amd64/tmp/java/java.lang/library/newclasses:../../../../../src/share/classes -bootclasspath /work/java.net/openjdk.orig/control/build/linux-amd64/lib/jce.jar -sourcepath /work/java.net/openjdk.orig/control/build/linux-amd64/gensrc:../../../../../src/solaris/classes:../../../../../src/share/classes -d /work/java.net/openjdk.orig/control/build/linux-amd64/tmp/java/java.lang/library/newclasses -encoding ascii -source 1.5 -target 5 @/work/java.net/openjdk.orig/control/build/linux-amd64/tmp/java/java.lang/.classes.list # # An unexpected error has been detected by Java Runtime Environment: # # Internal Error (relocInfo_amd64.cpp:67), pid=15028, tid=1077938496 # Error: ShouldNotReachHere() # # Java VM: OpenJDK 64-Bit Server VM ( 1.7.0-internal-freds_19_jul_2007_21_01-b00 mixed mode linux-amd64) # An error report file with more information is saved as: # /work/java.net/openjdk.orig/j2se/make/sun/javac/recompile/library/hs_err_pid15028.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted (core dumped) make[6]: *** [.compile.classlist] Error 134 make[6]: Leaving directory `/work/java.net/openjdk.orig/j2se/make/sun/javac/recompile/library' Anyone else got this. Any idea where I should look. The only modification to the source base is the above patch. Thanks in advance. On 7/19/07, Peter B. Kessler wrote: > > We (cough) independently discovered the compilation problem with > assembler_i486.hpp and gcc4.1.2. It's bug #6578344, e.g., > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578344 > and I can see it's fixed in our code base, so it will be published > in the next drop. > > ... peter > > Ted Neward wrote: > > Yep, had it pointing to the Import JDK (1.6) instead of the binary plug > JDK > > (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > > > > By the way, in case those on this list haven't seen it, the build on > Intel > > machines won't work, as there's a compilation error in a source file, as > > reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > > > > #### > > > > --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > > 10:29:14.412986944 -0700 > > +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > > 10:29:31.499389416 -0700 > > @@ -158,7 +158,7 @@ > > > > // Easily misused constructor make them private #ifndef _LP64 > > - Address::Address(address loc, RelocationHolder spec); > > + Address(address loc, RelocationHolder spec); > > #endif // _LP64 > > > > public: > > > > #### > > > > Peter Kessler reported it as already reported, a la > > > > http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > > > > but no official bug had been filed, and there was some concern about > Sunil's > > contributor status or whatnot. Not sure what happened to it from there. > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > -- http://freddy33.bglogspot.com/ http://www.jfrog.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at pbw.id.au Fri Jul 20 00:03:18 2007 From: lists at pbw.id.au (Peter B. West) Date: Fri, 20 Jul 2007 10:03:18 +1000 Subject: [Fwd: Re: Getting Started with OpenJDK in NetBeans IDE?] Message-ID: <469FFBC6.3050606@pbw.id.au> This thread started because I couldn't get jtreg to run against one of the JDK sub-projects in NetBeans. As a result, I tried to build the j2se project. My environment is SuSE 10.2, NB 6 build 200704122300 Java 1.6.0_01. I tried the build without specifying ALT_MOTIF_DIR, and was told I had no motif 2.1. I have openmotif-devel-2.3.0beta2-32 openmotif-libs-2.3.0beta2-32 openmotif-2.3.0beta2-32 installed. I then tried grabbing the OpenBSD i386 2.1.30 package, and setting ALT_MOTIF_DIR. That got me over the first hurdle, with the results shown below. Any suggestions? Peter -------- Original Message -------- Subject: Re: Getting Started with OpenJDK in NetBeans IDE? Date: Thu, 19 Jul 2007 12:44:11 -0700 From: Dave Bristor To: Peter B. West References: <468EFC3D.6010509 at pbw.id.au> <469262C9.8020403 at sun.com> <469B38AD.7000505 at pbw.id.au> <469CF973.2040708 at sun.com> <469F3D49.50601 at pbw.id.au> Hi Peter, I think your question is better posted to the build-dev at openjdk.java.net alias. If you can provide info re the distro your using, that might help. IIRC we tested on ubuntu and fedora. Dave Peter B. West wrote: > Dave Bristor wrote: > > ... > >>>Before getting to that point, and thinking I might need to do a prebuild >>>of j2se, I tried that from a terminal. At the moment, that build is not >>>working because, in spite of what the docs say, the build requires not >>>only the openmotif header files, but the libs as well. The openmotif >>>libs I have installed are too recent, so it looks as though I will have >>>to build a set an install them in a non-standard place if I need to >>>build the jdk. Haven't sorted that one out yet. >> >>The motif requirements are different for different OSs; cf the Ubuntu >>6.06 v. 7.04 notes; in particular that the latter does have motif >>dependencies (though I'm not sure this will resolve your problem without >>knowing more about your build environment/platform). I just checked my >>kubuntu 6.10 box, and seem to have headers+libs; YMMV. >> >> Dave >> > > > Dave, > > The first problem with the openmotif libraries is that the link points > to the hppa architecture's 2.1.30 package. Once I had corrected that, I > tried the build again. Here's a snatch of the output. > > [exec] > ../../../build/linux-i586/tmp/sun/sun.awt/motif21/obj/awt_motif21.o: In > function `awt_motif_getIMStatusHeight': > [exec] awt_motif21.c:(.text+0x426): undefined reference to > `_XmImGetGeo' > [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function > `DragKey': > [exec] DragC.c:(.text+0x2699): undefined reference to `__guard' > [exec] DragC.c:(.text+0x2785): undefined reference to `__guard' > [exec] DragC.c:(.text+0x279c): undefined reference to > `__stack_smash_handler' > [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function > `InitiatorMainLoop': > [exec] DragC.c:(.text+0x2d02): undefined reference to `__guard' > [exec] DragC.c:(.text+0x2d2c): undefined reference to > `__stack_smash_handler' > [exec] DragC.c:(.text+0x2eaa): undefined reference to `__guard' > > It goes on and on like that. It looks as though it's trying to build > motif 2.1, but not 2.1 as we know it, Jim. > > > -- Peter B. West Folio From mark at klomp.org Sun Jul 22 18:54:21 2007 From: mark at klomp.org (Mark Wielaard) Date: Sun, 22 Jul 2007 18:54:21 +0000 (UTC) Subject: T2K needed in Linux, also? References: <469F5E7A.2070504@sun.com> <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> Message-ID: Ted Neward writes: > Yep, had it pointing to the Import JDK (1.6) instead of the binary plug JDK > (1.7). Thanks. There's a lot of JDKs needed to build the JDK. There is also a project to free the JDK from "itself" :) http://iced-tea.org/ (soon to be back at the old url icedtea.classpath.org hopefully) Then you don't need any binary plugs nor a JDK installed when compiling on GNU/Linux. It will use the gcj compiler to build and provides free software alternatives for the plugs based on existing and newly written code. (And it contains build patches like you pointed out against the bxy drops when appropriate to make things bootstrap out of the box.) Discussion about it takes place on the GNU/Linux distro-pkg-dev OpenJDK mailinglist: http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev Cheers, Mark From lhofhansl at salesforce.com Sat Jul 21 01:16:44 2007 From: lhofhansl at salesforce.com (Lars Hofhansl) Date: Fri, 20 Jul 2007 18:16:44 -0700 Subject: DuctusRenderingEngine missing from PLUG_DC_CLASS_NAMES Message-ID: <46A44BAB89FAD04C97C12690276C72D8062064A8@exsfo-mb04.internal.salesforce.com> Minor build problem in j2se/make/common/BinaryPlugs.gmk (breaking Swing Apps) PLUG_DC_CLASS_NAMES is missing DuctusRenderingEngine. --- BinaryPlugs.gmk~ 2007-07-20 00:17:54.000000000 -0700 +++ BinaryPlugs.gmk 2007-07-20 18:09:52.000000000 -0700 @@ -306,6 +306,8 @@ sun/dc/pr/PathDasher.class \ sun/dc/pr/PathFiller.class \ sun/dc/pr/PathStroker.class \ +sun/dc/DuctusRenderingEngine$FillAdapter.class \ +sun/dc/DuctusRenderingEngine.class \ sun/dc/pr/Rasterizer\$$ConsumerDisposer.class \ sun/dc/pr/Rasterizer.class From ted at tedneward.com Wed Jul 25 07:32:20 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 25 Jul 2007 00:32:20 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <09a501c7ca27$b52ed8b0$802ca8c0@XPWork> Message-ID: <094701c7ce8d$f197b370$802ca8c0@XPWork> Next issue: after an svn update (which caught me up to rev 244, the latest in SVN), I do a Windows build, and it fails in the j2se/make/sun/font build, trying (of course) to build t2k.lib. The problem is, I can't figure out what it's looking for in order to slip t2k.lib into the right place and move on. Here's the results: CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font $ make /usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll lib= ../../../build/windows-i586/bin/fontmanager.dll make -C t2k make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' make[1]: *** No rule to make target `C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by `../../../../build/windows-i586/libfiles/t2k.lib'. Stop. make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' make: *** [t2k] Error 2 Where did this directory "libfiles" come from in the build step? My guess is it's coming from a variable/setting somewhere, but I can't figure out what to set in order to help the build system find my cribbed t2k.lib so it can move on. And even if I create said directories (both in the BinaryPlugs dir and the build dir), and put t2k.lib in there, the build still fails. Help? BTW, in general, how does one debug the build process? 'make -d' just seems horrendous.... Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Ted Neward > Sent: Thursday, July 19, 2007 10:10 AM > To: Phil.Race at Sun.COM > Cc: build-dev at openjdk.java.net > Subject: RE: T2K needed in Linux, also? > > Yep, had it pointing to the Import JDK (1.6) instead of the binary plug > JDK > (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > > By the way, in case those on this list haven't seen it, the build on Intel > machines won't work, as there's a compilation error in a source file, as > reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > > #### > > --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > 10:29:14.412986944 -0700 > +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > 10:29:31.499389416 -0700 > @@ -158,7 +158,7 @@ > > // Easily misused constructor make them private #ifndef _LP64 > - Address::Address(address loc, RelocationHolder spec); > + Address(address loc, RelocationHolder spec); > #endif // _LP64 > > public: > > #### > > Peter Kessler reported it as already reported, a la > > http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > > but no official bug had been filed, and there was some concern about > Sunil's > contributor status or whatnot. Not sure what happened to it from there. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > > Sent: Thursday, July 19, 2007 5:52 AM > > To: Ted Neward > > Cc: build-dev at openjdk.java.net > > Subject: Re: T2K needed in Linux, also? > > > > Ted Neward wrote: > > > > > > When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > > > build error saying libt2k.so cannot be found. Am I missing something? > > > > > > > Yes, sounds like you are missing the entire binary plug download, or > > haven't properly pointed to it's location. > > > > -phil. > > > > > > > > > > > Ted Neward > > > > > > Java, .NET, XML Services > > > > > > Consulting, Teaching, Speaking, Writing > > > > > > http://www.tedneward.com > > > > > > > > > > > > > > > > > > > > > No virus found in this outgoing message. > > > Checked by AVG Free Edition. > > > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > > > 7/17/2007 6:30 PM > > > > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > 7/17/2007 > > 6:30 PM > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007 > 3:30 PM > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007 > 3:30 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 1:50 PM From Kelly.Ohair at Sun.COM Sat Jul 28 21:14:39 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 28 Jul 2007 14:14:39 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <094701c7ce8d$f197b370$802ca8c0@XPWork> References: <094701c7ce8d$f197b370$802ca8c0@XPWork> Message-ID: <46ABB1BF.2090002@sun.com> The new sparse binary plugs will have the same exact layout as a jdk install tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. With one additional directory called "libfiles". This is where t2k.lib will be found, however, look quickly, because it may be deleted from the binary plugs soon and won't even be needed anymore. So anything you do around t2k.lib may be a bit of a waste of time. The new sparse binary plugs are awaiting some legal issues and should be showing up any day now. The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with the binary plugs and has a rule that will copy the t2k.lib file into the right place when the make/sun/font/Makefile is run. There is an export and import process for the BinaryPlugs. As the different engineering groups remove the need for plugs, this file should get smaller and smaller, as will the size of the binary plugs which will be created automatically soon. Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk right now: ------- BinaryPlugs.gmk ------- *** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 --- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 *************** *** 448,453 **** --- 448,454 ---- import-binary-plug-t2k-library: \ $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) $(RM) $(OBJDIR)/t2k.lib + $(MKDIR) -p $(OBJDIR) $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) else # !windows import-binary-plug-t2k-library: \ At least that's what we think prevents the new sparse binary plug bundles from allowing an OpenJDK build on windows to work right now. We were testing windows builds last week just before I took off on a short vacation. You could simulate things by creating this "libfiles" directory and placing your t2k.lib file in it. As far as debugging the build process, it's not easy, but it has been getting better over the last few releases. Expect more build changes in the future with a goal of simplification. Try 'gnumake -p', or there was a recent article in Dr. Dobbs about debugging makefiles that was very helpful. Last month maybe or 2 months ago? -kto Ted Neward wrote: > Next issue: after an svn update (which caught me up to rev 244, the latest > in SVN), I do a Windows build, and it fails in the j2se/make/sun/font build, > trying (of course) to build t2k.lib. The problem is, I can't figure out what > it's looking for in order to slip t2k.lib into the right place and move on. > Here's the results: > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font > $ make > /usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll > lib= ../../../build/windows-i586/bin/fontmanager.dll > make -C t2k > make[1]: Entering directory > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > make[1]: *** No rule to make target > `C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by > `../../../../build/windows-i586/libfiles/t2k.lib'. Stop. > make[1]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > make: *** [t2k] Error 2 > > Where did this directory "libfiles" come from in the build step? My guess is > it's coming from a variable/setting somewhere, but I can't figure out what > to set in order to help the build system find my cribbed t2k.lib so it can > move on. And even if I create said directories (both in the BinaryPlugs dir > and the build dir), and put t2k.lib in there, the build still fails. > > Help? > > BTW, in general, how does one debug the build process? 'make -d' just seems > horrendous.... > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >> bounces at openjdk.java.net] On Behalf Of Ted Neward >> Sent: Thursday, July 19, 2007 10:10 AM >> To: Phil.Race at Sun.COM >> Cc: build-dev at openjdk.java.net >> Subject: RE: T2K needed in Linux, also? >> >> Yep, had it pointing to the Import JDK (1.6) instead of the binary plug >> JDK >> (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) >> >> By the way, in case those on this list haven't seen it, the build on Intel >> machines won't work, as there's a compilation error in a source file, as >> reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: >> >> #### >> >> --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 >> 10:29:14.412986944 -0700 >> +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 >> 10:29:31.499389416 -0700 >> @@ -158,7 +158,7 @@ >> >> // Easily misused constructor make them private #ifndef _LP64 >> - Address::Address(address loc, RelocationHolder spec); >> + Address(address loc, RelocationHolder spec); >> #endif // _LP64 >> >> public: >> >> #### >> >> Peter Kessler reported it as already reported, a la >> >> http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html >> >> but no official bug had been filed, and there was some concern about >> Sunil's >> contributor status or whatnot. Not sure what happened to it from there. >> >> Ted Neward >> Java, .NET, XML Services >> Consulting, Teaching, Speaking, Writing >> http://www.tedneward.com >> >> >>> -----Original Message----- >>> From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] >>> Sent: Thursday, July 19, 2007 5:52 AM >>> To: Ted Neward >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: T2K needed in Linux, also? >>> >>> Ted Neward wrote: >>>> When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a >>>> build error saying libt2k.so cannot be found. Am I missing something? >>>> >>> Yes, sounds like you are missing the entire binary plug download, or >>> haven't properly pointed to it's location. >>> >>> -phil. >>> >>>> >>>> Ted Neward >>>> >>>> Java, .NET, XML Services >>>> >>>> Consulting, Teaching, Speaking, Writing >>>> >>>> http://www.tedneward.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> No virus found in this outgoing message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >>>> 7/17/2007 6:30 PM >>>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >> 7/17/2007 >>> 6:30 PM >>> >> No virus found in this outgoing message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007 >> 3:30 PM >> >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007 >> 3:30 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 > 1:50 PM > > From Kelly.Ohair at Sun.COM Sat Jul 28 21:22:23 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 28 Jul 2007 14:22:23 -0700 Subject: [Fwd: Re: Getting Started with OpenJDK in NetBeans IDE?] In-Reply-To: <469FFBC6.3050606@pbw.id.au> References: <469FFBC6.3050606@pbw.id.au> Message-ID: <46ABB38F.2000803@sun.com> Where did you get these jdk sources? The OpenJDK sources should not have a dependence on Motif libraries, just Motif include files. -kto Peter B. West wrote: > This thread started because I couldn't get jtreg to run against one of > the JDK sub-projects in NetBeans. As a result, I tried to build the j2se > project. > > My environment is SuSE 10.2, NB 6 build 200704122300 Java 1.6.0_01. I > tried the build without specifying ALT_MOTIF_DIR, and was told I had no > motif 2.1. I have > openmotif-devel-2.3.0beta2-32 > openmotif-libs-2.3.0beta2-32 > openmotif-2.3.0beta2-32 > > installed. > > I then tried grabbing the OpenBSD i386 2.1.30 package, and setting > ALT_MOTIF_DIR. That got me over the first hurdle, with the results shown > below. > > Any suggestions? > > Peter > > -------- Original Message -------- > Subject: Re: Getting Started with OpenJDK in NetBeans IDE? > Date: Thu, 19 Jul 2007 12:44:11 -0700 > From: Dave Bristor > To: Peter B. West > References: <468EFC3D.6010509 at pbw.id.au> <469262C9.8020403 at sun.com> > <469B38AD.7000505 at pbw.id.au> <469CF973.2040708 at sun.com> > <469F3D49.50601 at pbw.id.au> > > Hi Peter, I think your question is better posted to the > build-dev at openjdk.java.net alias. If you can provide info re the distro > your > using, that might help. IIRC we tested on ubuntu and fedora. > > Dave > > Peter B. West wrote: >> Dave Bristor wrote: >> >> ... >> >>>> Before getting to that point, and thinking I might need to do a prebuild >>>> of j2se, I tried that from a terminal. At the moment, that build is not >>>> working because, in spite of what the docs say, the build requires not >>>> only the openmotif header files, but the libs as well. The openmotif >>>> libs I have installed are too recent, so it looks as though I will have >>>> to build a set an install them in a non-standard place if I need to >>>> build the jdk. Haven't sorted that one out yet. >>> The motif requirements are different for different OSs; cf the Ubuntu >>> 6.06 v. 7.04 notes; in particular that the latter does have motif >>> dependencies (though I'm not sure this will resolve your problem without >>> knowing more about your build environment/platform). I just checked my >>> kubuntu 6.10 box, and seem to have headers+libs; YMMV. >>> >>> Dave >>> >> >> Dave, >> >> The first problem with the openmotif libraries is that the link points >> to the hppa architecture's 2.1.30 package. Once I had corrected that, I >> tried the build again. Here's a snatch of the output. >> >> [exec] >> ../../../build/linux-i586/tmp/sun/sun.awt/motif21/obj/awt_motif21.o: In >> function `awt_motif_getIMStatusHeight': >> [exec] awt_motif21.c:(.text+0x426): undefined reference to >> `_XmImGetGeo' >> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function >> `DragKey': >> [exec] DragC.c:(.text+0x2699): undefined reference to `__guard' >> [exec] DragC.c:(.text+0x2785): undefined reference to `__guard' >> [exec] DragC.c:(.text+0x279c): undefined reference to >> `__stack_smash_handler' >> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function >> `InitiatorMainLoop': >> [exec] DragC.c:(.text+0x2d02): undefined reference to `__guard' >> [exec] DragC.c:(.text+0x2d2c): undefined reference to >> `__stack_smash_handler' >> [exec] DragC.c:(.text+0x2eaa): undefined reference to `__guard' >> >> It goes on and on like that. It looks as though it's trying to build >> motif 2.1, but not 2.1 as we know it, Jim. >> >> >> > > > > From lists at pbw.id.au Sun Jul 29 01:19:14 2007 From: lists at pbw.id.au (Peter B. West) Date: Sun, 29 Jul 2007 11:19:14 +1000 Subject: [Fwd: Re: Getting Started with OpenJDK in NetBeans IDE?] In-Reply-To: <46ABB38F.2000803@sun.com> References: <469FFBC6.3050606@pbw.id.au> <46ABB38F.2000803@sun.com> Message-ID: <1185671954.18765.5.camel@jezebel.local> On Sat, 2007-07-28 at 14:22 -0700, Kelly O'Hair wrote: > Where did you get these jdk sources? > >From the source bundles of the OpenJDK project. Unfortunately, I have not retained the bundle I downloaded, but I think it was the bundle from the 15th of July. I'll try the latest bundle. > The OpenJDK sources should not have a dependence on Motif libraries, > just Motif include files. > > -kto > > Peter B. West wrote: > > This thread started because I couldn't get jtreg to run against one of > > the JDK sub-projects in NetBeans. As a result, I tried to build the j2se > > project. > > > > My environment is SuSE 10.2, NB 6 build 200704122300 Java 1.6.0_01. I > > tried the build without specifying ALT_MOTIF_DIR, and was told I had no > > motif 2.1. I have > > openmotif-devel-2.3.0beta2-32 > > openmotif-libs-2.3.0beta2-32 > > openmotif-2.3.0beta2-32 > > > > installed. > > > > I then tried grabbing the OpenBSD i386 2.1.30 package, and setting > > ALT_MOTIF_DIR. That got me over the first hurdle, with the results shown > > below. > > > > Any suggestions? > > > > Peter > > > > -------- Original Message -------- > > Subject: Re: Getting Started with OpenJDK in NetBeans IDE? > > Date: Thu, 19 Jul 2007 12:44:11 -0700 > > From: Dave Bristor > > To: Peter B. West > > References: <468EFC3D.6010509 at pbw.id.au> <469262C9.8020403 at sun.com> > > <469B38AD.7000505 at pbw.id.au> <469CF973.2040708 at sun.com> > > <469F3D49.50601 at pbw.id.au> > > > > Hi Peter, I think your question is better posted to the > > build-dev at openjdk.java.net alias. If you can provide info re the distro > > your > > using, that might help. IIRC we tested on ubuntu and fedora. > > > > Dave > > > > Peter B. West wrote: > >> Dave Bristor wrote: > >> > >> ... > >> > >>>> Before getting to that point, and thinking I might need to do a prebuild > >>>> of j2se, I tried that from a terminal. At the moment, that build is not > >>>> working because, in spite of what the docs say, the build requires not > >>>> only the openmotif header files, but the libs as well. The openmotif > >>>> libs I have installed are too recent, so it looks as though I will have > >>>> to build a set an install them in a non-standard place if I need to > >>>> build the jdk. Haven't sorted that one out yet. > >>> The motif requirements are different for different OSs; cf the Ubuntu > >>> 6.06 v. 7.04 notes; in particular that the latter does have motif > >>> dependencies (though I'm not sure this will resolve your problem without > >>> knowing more about your build environment/platform). I just checked my > >>> kubuntu 6.10 box, and seem to have headers+libs; YMMV. > >>> > >>> Dave > >>> > >> > >> Dave, > >> > >> The first problem with the openmotif libraries is that the link points > >> to the hppa architecture's 2.1.30 package. Once I had corrected that, I > >> tried the build again. Here's a snatch of the output. > >> > >> [exec] > >> ../../../build/linux-i586/tmp/sun/sun.awt/motif21/obj/awt_motif21.o: In > >> function `awt_motif_getIMStatusHeight': > >> [exec] awt_motif21.c:(.text+0x426): undefined reference to > >> `_XmImGetGeo' > >> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function > >> `DragKey': > >> [exec] DragC.c:(.text+0x2699): undefined reference to `__guard' > >> [exec] DragC.c:(.text+0x2785): undefined reference to `__guard' > >> [exec] DragC.c:(.text+0x279c): undefined reference to > >> `__stack_smash_handler' > >> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function > >> `InitiatorMainLoop': > >> [exec] DragC.c:(.text+0x2d02): undefined reference to `__guard' > >> [exec] DragC.c:(.text+0x2d2c): undefined reference to > >> `__stack_smash_handler' > >> [exec] DragC.c:(.text+0x2eaa): undefined reference to `__guard' > >> > >> It goes on and on like that. It looks as though it's trying to build > >> motif 2.1, but not 2.1 as we know it, Jim. > >> > >> > >> > > > > > > > > > > From Kelly.Ohair at Sun.COM Sun Jul 29 21:52:04 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 29 Jul 2007 14:52:04 -0700 Subject: [Fwd: Re: Getting Started with OpenJDK in NetBeans IDE?] In-Reply-To: <1185671954.18765.5.camel@jezebel.local> References: <469FFBC6.3050606@pbw.id.au> <46ABB38F.2000803@sun.com> <1185671954.18765.5.camel@jezebel.local> Message-ID: <46AD0C04.3010302@sun.com> Normally when building OpenJDK, the make variable OPENJDK should get set to true. This happens automatically when the makefiles detect that certain directories are missing, but I suppose this could be broken. Try using an explicit: make OPENJDK=true Or set OPENJDK as an environment variable, set to "true". I'm suspecting that you have somehow fallen into a build that is not an OPENJDK build (the makefiles are the same for OpenJDK and JDK). We hope to completely remove our dependence on Motif in jdk7, or at least I think that is the plan. I certainly won't miss this dependence, it's quite convoluted how it hooks into the build process. Are there any environment variables set with MOTIF in their name? e.g. env | grep MOTIF -kto Peter B. West wrote: > On Sat, 2007-07-28 at 14:22 -0700, Kelly O'Hair wrote: >> Where did you get these jdk sources? >> > >>From the source bundles of the OpenJDK project. Unfortunately, I have > not retained the bundle I downloaded, but I think it was the bundle from > the 15th of July. I'll try the latest bundle. > >> The OpenJDK sources should not have a dependence on Motif libraries, >> just Motif include files. >> >> -kto >> >> Peter B. West wrote: >>> This thread started because I couldn't get jtreg to run against one of >>> the JDK sub-projects in NetBeans. As a result, I tried to build the j2se >>> project. >>> >>> My environment is SuSE 10.2, NB 6 build 200704122300 Java 1.6.0_01. I >>> tried the build without specifying ALT_MOTIF_DIR, and was told I had no >>> motif 2.1. I have >>> openmotif-devel-2.3.0beta2-32 >>> openmotif-libs-2.3.0beta2-32 >>> openmotif-2.3.0beta2-32 >>> >>> installed. >>> >>> I then tried grabbing the OpenBSD i386 2.1.30 package, and setting >>> ALT_MOTIF_DIR. That got me over the first hurdle, with the results shown >>> below. >>> >>> Any suggestions? >>> >>> Peter >>> >>> -------- Original Message -------- >>> Subject: Re: Getting Started with OpenJDK in NetBeans IDE? >>> Date: Thu, 19 Jul 2007 12:44:11 -0700 >>> From: Dave Bristor >>> To: Peter B. West >>> References: <468EFC3D.6010509 at pbw.id.au> <469262C9.8020403 at sun.com> >>> <469B38AD.7000505 at pbw.id.au> <469CF973.2040708 at sun.com> >>> <469F3D49.50601 at pbw.id.au> >>> >>> Hi Peter, I think your question is better posted to the >>> build-dev at openjdk.java.net alias. If you can provide info re the distro >>> your >>> using, that might help. IIRC we tested on ubuntu and fedora. >>> >>> Dave >>> >>> Peter B. West wrote: >>>> Dave Bristor wrote: >>>> >>>> ... >>>> >>>>>> Before getting to that point, and thinking I might need to do a prebuild >>>>>> of j2se, I tried that from a terminal. At the moment, that build is not >>>>>> working because, in spite of what the docs say, the build requires not >>>>>> only the openmotif header files, but the libs as well. The openmotif >>>>>> libs I have installed are too recent, so it looks as though I will have >>>>>> to build a set an install them in a non-standard place if I need to >>>>>> build the jdk. Haven't sorted that one out yet. >>>>> The motif requirements are different for different OSs; cf the Ubuntu >>>>> 6.06 v. 7.04 notes; in particular that the latter does have motif >>>>> dependencies (though I'm not sure this will resolve your problem without >>>>> knowing more about your build environment/platform). I just checked my >>>>> kubuntu 6.10 box, and seem to have headers+libs; YMMV. >>>>> >>>>> Dave >>>>> >>>> Dave, >>>> >>>> The first problem with the openmotif libraries is that the link points >>>> to the hppa architecture's 2.1.30 package. Once I had corrected that, I >>>> tried the build again. Here's a snatch of the output. >>>> >>>> [exec] >>>> ../../../build/linux-i586/tmp/sun/sun.awt/motif21/obj/awt_motif21.o: In >>>> function `awt_motif_getIMStatusHeight': >>>> [exec] awt_motif21.c:(.text+0x426): undefined reference to >>>> `_XmImGetGeo' >>>> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function >>>> `DragKey': >>>> [exec] DragC.c:(.text+0x2699): undefined reference to `__guard' >>>> [exec] DragC.c:(.text+0x2785): undefined reference to `__guard' >>>> [exec] DragC.c:(.text+0x279c): undefined reference to >>>> `__stack_smash_handler' >>>> [exec] /home/pbw/src/openmotif/lib/libXm.a(DragC.o): In function >>>> `InitiatorMainLoop': >>>> [exec] DragC.c:(.text+0x2d02): undefined reference to `__guard' >>>> [exec] DragC.c:(.text+0x2d2c): undefined reference to >>>> `__stack_smash_handler' >>>> [exec] DragC.c:(.text+0x2eaa): undefined reference to `__guard' >>>> >>>> It goes on and on like that. It looks as though it's trying to build >>>> motif 2.1, but not 2.1 as we know it, Jim. >>>> >>>> >>>> >>> >>> >>> >> > From ted at tedneward.com Sun Jul 29 23:55:23 2007 From: ted at tedneward.com (Ted Neward) Date: Sun, 29 Jul 2007 16:55:23 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <46ABB1BF.2090002@sun.com> Message-ID: <08ad01c7d23b$ef4f3f00$802ca8c0@XPWork> I slipped in the patch below, copied t2k.lib to the BinaryPlugs\jdk1.7.0\libfiles directory, did "make" in make/sun/font, and it appears to work. I'm doing a "make clean" / "make debug_build" now to see if it'll run from start to finish, just to verify everything. Will post results when that's done, which may take a few days.... ;-) BTW, Kelly (and Phil), major kudos to you guys, both for putting up with my idiot questions, and for streamlining the build process significantly. I may complain about the process and critique the decisions made, but please don't ever take that to imply criticism of you guys or your work. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Saturday, July 28, 2007 2:15 PM > To: Ted Neward > Cc: Phil.Race at Sun.COM; build-dev at openjdk.java.net > Subject: Re: T2K needed in Linux, also? > > The new sparse binary plugs will have the same exact layout as a jdk > install > tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. > With one additional directory called "libfiles". This is where t2k.lib > will be found, > however, look quickly, because it may be deleted from the binary plugs > soon > and won't even be needed anymore. So anything you do around t2k.lib may be > a bit > of a waste of time. The new sparse binary plugs are awaiting some legal > issues > and should be showing up any day now. > > The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with > the > binary plugs and has a rule that will copy the t2k.lib file into the right > place when the make/sun/font/Makefile is run. There is an export and > import > process for the BinaryPlugs. As the different engineering groups remove > the need for plugs, this file should get smaller and smaller, as will the > size of the binary plugs which will be created automatically soon. > > Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk > right > now: > > ------- BinaryPlugs.gmk ------- > *** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 > --- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 > *************** > *** 448,453 **** > --- 448,454 ---- > import-binary-plug-t2k-library: \ > $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) > $(RM) $(OBJDIR)/t2k.lib > + $(MKDIR) -p $(OBJDIR) > $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) > else # !windows > import-binary-plug-t2k-library: \ > > At least that's what we think prevents the new sparse binary plug bundles > from allowing an OpenJDK build on windows to work right now. > We were testing windows builds last week just before I took off on a > short vacation. > You could simulate things by creating this "libfiles" directory and > placing > your t2k.lib file in it. > > As far as debugging the build process, it's not easy, but it has been > getting better over the last few releases. > Expect more build changes in the future with a goal of simplification. > > Try 'gnumake -p', or there was a recent article in Dr. Dobbs about > debugging > makefiles that was very helpful. Last month maybe or 2 months ago? > > -kto > > > Ted Neward wrote: > > Next issue: after an svn update (which caught me up to rev 244, the > latest > > in SVN), I do a Windows build, and it fails in the j2se/make/sun/font > build, > > trying (of course) to build t2k.lib. The problem is, I can't figure out > what > > it's looking for in order to slip t2k.lib into the right place and move > on. > > Here's the results: > > > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font > > $ make > > /usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll > > lib= ../../../build/windows-i586/bin/fontmanager.dll > > make -C t2k > > make[1]: Entering directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > > make[1]: *** No rule to make target > > `C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by > > `../../../../build/windows-i586/libfiles/t2k.lib'. Stop. > > make[1]: Leaving directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > > make: *** [t2k] Error 2 > > > > Where did this directory "libfiles" come from in the build step? My > guess is > > it's coming from a variable/setting somewhere, but I can't figure out > what > > to set in order to help the build system find my cribbed t2k.lib so it > can > > move on. And even if I create said directories (both in the BinaryPlugs > dir > > and the build dir), and put t2k.lib in there, the build still fails. > > > > Help? > > > > BTW, in general, how does one debug the build process? 'make -d' just > seems > > horrendous.... > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > >> bounces at openjdk.java.net] On Behalf Of Ted Neward > >> Sent: Thursday, July 19, 2007 10:10 AM > >> To: Phil.Race at Sun.COM > >> Cc: build-dev at openjdk.java.net > >> Subject: RE: T2K needed in Linux, also? > >> > >> Yep, had it pointing to the Import JDK (1.6) instead of the binary plug > >> JDK > >> (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > >> > >> By the way, in case those on this list haven't seen it, the build on > Intel > >> machines won't work, as there's a compilation error in a source file, > as > >> reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > >> > >> #### > >> > >> --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > >> 10:29:14.412986944 -0700 > >> +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > >> 10:29:31.499389416 -0700 > >> @@ -158,7 +158,7 @@ > >> > >> // Easily misused constructor make them private #ifndef _LP64 > >> - Address::Address(address loc, RelocationHolder spec); > >> + Address(address loc, RelocationHolder spec); > >> #endif // _LP64 > >> > >> public: > >> > >> #### > >> > >> Peter Kessler reported it as already reported, a la > >> > >> http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > >> > >> but no official bug had been filed, and there was some concern about > >> Sunil's > >> contributor status or whatnot. Not sure what happened to it from there. > >> > >> Ted Neward > >> Java, .NET, XML Services > >> Consulting, Teaching, Speaking, Writing > >> http://www.tedneward.com > >> > >> > >>> -----Original Message----- > >>> From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > >>> Sent: Thursday, July 19, 2007 5:52 AM > >>> To: Ted Neward > >>> Cc: build-dev at openjdk.java.net > >>> Subject: Re: T2K needed in Linux, also? > >>> > >>> Ted Neward wrote: > >>>> When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > >>>> build error saying libt2k.so cannot be found. Am I missing something? > >>>> > >>> Yes, sounds like you are missing the entire binary plug download, or > >>> haven't properly pointed to it's location. > >>> > >>> -phil. > >>> > >>>> > >>>> Ted Neward > >>>> > >>>> Java, .NET, XML Services > >>>> > >>>> Consulting, Teaching, Speaking, Writing > >>>> > >>>> http://www.tedneward.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> No virus found in this outgoing message. > >>>> Checked by AVG Free Edition. > >>>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >>>> 7/17/2007 6:30 PM > >>>> > >>> No virus found in this incoming message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >> 7/17/2007 > >>> 6:30 PM > >>> > >> No virus found in this outgoing message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > 7/18/2007 > >> 3:30 PM > >> > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > 7/18/2007 > >> 3:30 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: > 7/24/2007 > > 1:50 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007 > 2:55 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM From ted at tedneward.com Mon Jul 30 00:01:26 2007 From: ted at tedneward.com (Ted Neward) Date: Sun, 29 Jul 2007 17:01:26 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <46ABB1BF.2090002@sun.com> Message-ID: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> Quick note: doing a "make clean" from the top yielded this: $ make clean rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/outputdir rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import ( cd ../../j2se/make; make clobber EXTERNALSANITYCONTROL=true MILESTONE=private BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-private-b00 ALT_OUTPUT DIR=c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 ALT_HOTSPOT_IMPORT_PATH=c:/Prg /OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import BUILD_HOTSPOT=true BUILD_ MOTIF=false ARCH_DATA_MODEL=32 ; ) make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' ../make/common/shared/Defs-windows.gmk:611: "WARNING: Value of HOTSPOT_IMPORT_PA TH cannot be empty, check or set ALT_HOTSPOT_IMPORT_PATH" rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 rm: cannot remove directory `c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1': Dir ectory not empty make[1]: *** [clobber] Error 1 make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' make: *** [j2se-clobber] Error 2 CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make $ Not sure if there was something in particular I needed to do to make the clean target work, but I "fixed" it by just nuking the build/* directories by hand. However, this doesn't exactly work, as apparently "make clean" *creates* directories underneath build (build/windows-i586, in particular) as part of cleaning the build. :-) I suspect this to be a bug, yes? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Saturday, July 28, 2007 2:15 PM > To: Ted Neward > Cc: Phil.Race at Sun.COM; build-dev at openjdk.java.net > Subject: Re: T2K needed in Linux, also? > > The new sparse binary plugs will have the same exact layout as a jdk > install > tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. > With one additional directory called "libfiles". This is where t2k.lib > will be found, > however, look quickly, because it may be deleted from the binary plugs > soon > and won't even be needed anymore. So anything you do around t2k.lib may be > a bit > of a waste of time. The new sparse binary plugs are awaiting some legal > issues > and should be showing up any day now. > > The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with > the > binary plugs and has a rule that will copy the t2k.lib file into the right > place when the make/sun/font/Makefile is run. There is an export and > import > process for the BinaryPlugs. As the different engineering groups remove > the need for plugs, this file should get smaller and smaller, as will the > size of the binary plugs which will be created automatically soon. > > Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk > right > now: > > ------- BinaryPlugs.gmk ------- > *** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 > --- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 > *************** > *** 448,453 **** > --- 448,454 ---- > import-binary-plug-t2k-library: \ > $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) > $(RM) $(OBJDIR)/t2k.lib > + $(MKDIR) -p $(OBJDIR) > $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) > else # !windows > import-binary-plug-t2k-library: \ > > At least that's what we think prevents the new sparse binary plug bundles > from allowing an OpenJDK build on windows to work right now. > We were testing windows builds last week just before I took off on a > short vacation. > You could simulate things by creating this "libfiles" directory and > placing > your t2k.lib file in it. > > As far as debugging the build process, it's not easy, but it has been > getting better over the last few releases. > Expect more build changes in the future with a goal of simplification. > > Try 'gnumake -p', or there was a recent article in Dr. Dobbs about > debugging > makefiles that was very helpful. Last month maybe or 2 months ago? > > -kto > > > Ted Neward wrote: > > Next issue: after an svn update (which caught me up to rev 244, the > latest > > in SVN), I do a Windows build, and it fails in the j2se/make/sun/font > build, > > trying (of course) to build t2k.lib. The problem is, I can't figure out > what > > it's looking for in order to slip t2k.lib into the right place and move > on. > > Here's the results: > > > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font > > $ make > > /usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll > > lib= ../../../build/windows-i586/bin/fontmanager.dll > > make -C t2k > > make[1]: Entering directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > > make[1]: *** No rule to make target > > `C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by > > `../../../../build/windows-i586/libfiles/t2k.lib'. Stop. > > make[1]: Leaving directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > > make: *** [t2k] Error 2 > > > > Where did this directory "libfiles" come from in the build step? My > guess is > > it's coming from a variable/setting somewhere, but I can't figure out > what > > to set in order to help the build system find my cribbed t2k.lib so it > can > > move on. And even if I create said directories (both in the BinaryPlugs > dir > > and the build dir), and put t2k.lib in there, the build still fails. > > > > Help? > > > > BTW, in general, how does one debug the build process? 'make -d' just > seems > > horrendous.... > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > >> bounces at openjdk.java.net] On Behalf Of Ted Neward > >> Sent: Thursday, July 19, 2007 10:10 AM > >> To: Phil.Race at Sun.COM > >> Cc: build-dev at openjdk.java.net > >> Subject: RE: T2K needed in Linux, also? > >> > >> Yep, had it pointing to the Import JDK (1.6) instead of the binary plug > >> JDK > >> (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > >> > >> By the way, in case those on this list haven't seen it, the build on > Intel > >> machines won't work, as there's a compilation error in a source file, > as > >> reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > >> > >> #### > >> > >> --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > >> 10:29:14.412986944 -0700 > >> +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > >> 10:29:31.499389416 -0700 > >> @@ -158,7 +158,7 @@ > >> > >> // Easily misused constructor make them private #ifndef _LP64 > >> - Address::Address(address loc, RelocationHolder spec); > >> + Address(address loc, RelocationHolder spec); > >> #endif // _LP64 > >> > >> public: > >> > >> #### > >> > >> Peter Kessler reported it as already reported, a la > >> > >> http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > >> > >> but no official bug had been filed, and there was some concern about > >> Sunil's > >> contributor status or whatnot. Not sure what happened to it from there. > >> > >> Ted Neward > >> Java, .NET, XML Services > >> Consulting, Teaching, Speaking, Writing > >> http://www.tedneward.com > >> > >> > >>> -----Original Message----- > >>> From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > >>> Sent: Thursday, July 19, 2007 5:52 AM > >>> To: Ted Neward > >>> Cc: build-dev at openjdk.java.net > >>> Subject: Re: T2K needed in Linux, also? > >>> > >>> Ted Neward wrote: > >>>> When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > >>>> build error saying libt2k.so cannot be found. Am I missing something? > >>>> > >>> Yes, sounds like you are missing the entire binary plug download, or > >>> haven't properly pointed to it's location. > >>> > >>> -phil. > >>> > >>>> > >>>> Ted Neward > >>>> > >>>> Java, .NET, XML Services > >>>> > >>>> Consulting, Teaching, Speaking, Writing > >>>> > >>>> http://www.tedneward.com > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> No virus found in this outgoing message. > >>>> Checked by AVG Free Edition. > >>>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >>>> 7/17/2007 6:30 PM > >>>> > >>> No virus found in this incoming message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >> 7/17/2007 > >>> 6:30 PM > >>> > >> No virus found in this outgoing message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > 7/18/2007 > >> 3:30 PM > >> > >> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > 7/18/2007 > >> 3:30 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: > 7/24/2007 > > 1:50 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007 > 2:55 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM From Martin.Buchholz at Sun.COM Mon Jul 30 00:06:07 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Sun, 29 Jul 2007 17:06:07 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> References: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> Message-ID: <46AD2B6F.3000305@sun.com> I don't think JDK engineers do "make clean" very much. They either do "make clobber", or the crude yet effective rm -rf ../build; make ... Martin Ted Neward wrote: > Quick note: doing a "make clean" from the top yielded this: > > $ make clean > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/outputdir > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import > ( cd ../../j2se/make; make clobber EXTERNALSANITYCONTROL=true > MILESTONE=private > BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-private-b00 > ALT_OUTPUT > DIR=c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > ALT_HOTSPOT_IMPORT_PATH=c:/Prg > /OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import BUILD_HOTSPOT=true > BUILD_ > MOTIF=false ARCH_DATA_MODEL=32 ; ) > make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > ../make/common/shared/Defs-windows.gmk:611: "WARNING: Value of > HOTSPOT_IMPORT_PA > TH cannot be empty, check or set ALT_HOTSPOT_IMPORT_PATH" > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > rm: cannot remove directory `c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1': > Dir > ectory not empty > make[1]: *** [clobber] Error 1 > make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > make: *** [j2se-clobber] Error 2 > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > $ > > Not sure if there was something in particular I needed to do to make the > clean target work, but I "fixed" it by just nuking the build/* directories > by hand. However, this doesn't exactly work, as apparently "make clean" > *creates* directories underneath build (build/windows-i586, in particular) > as part of cleaning the build. :-) > > I suspect this to be a bug, yes? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >>-----Original Message----- >>From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >>Sent: Saturday, July 28, 2007 2:15 PM >>To: Ted Neward >>Cc: Phil.Race at Sun.COM; build-dev at openjdk.java.net >>Subject: Re: T2K needed in Linux, also? >> >>The new sparse binary plugs will have the same exact layout as a jdk >>install >>tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. >>With one additional directory called "libfiles". This is where t2k.lib >>will be found, >>however, look quickly, because it may be deleted from the binary plugs >>soon >>and won't even be needed anymore. So anything you do around t2k.lib may be >>a bit >>of a waste of time. The new sparse binary plugs are awaiting some legal >>issues >>and should be showing up any day now. >> >>The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with >>the >>binary plugs and has a rule that will copy the t2k.lib file into the right >>place when the make/sun/font/Makefile is run. There is an export and >>import >>process for the BinaryPlugs. As the different engineering groups remove >>the need for plugs, this file should get smaller and smaller, as will the >>size of the binary plugs which will be created automatically soon. >> >>Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk >>right >>now: >> >>------- BinaryPlugs.gmk ------- >>*** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 >>--- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 >>*************** >>*** 448,453 **** >>--- 448,454 ---- >> import-binary-plug-t2k-library: \ >> $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) >> $(RM) $(OBJDIR)/t2k.lib >>+ $(MKDIR) -p $(OBJDIR) >> $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) >> else # !windows >> import-binary-plug-t2k-library: \ >> >>At least that's what we think prevents the new sparse binary plug bundles >>from allowing an OpenJDK build on windows to work right now. >>We were testing windows builds last week just before I took off on a >>short vacation. >>You could simulate things by creating this "libfiles" directory and >>placing >>your t2k.lib file in it. >> >>As far as debugging the build process, it's not easy, but it has been >>getting better over the last few releases. >>Expect more build changes in the future with a goal of simplification. >> >>Try 'gnumake -p', or there was a recent article in Dr. Dobbs about >>debugging >>makefiles that was very helpful. Last month maybe or 2 months ago? >> >>-kto >> >> >>Ted Neward wrote: >>>Next issue: after an svn update (which caught me up to rev 244, the >>latest >>>in SVN), I do a Windows build, and it fails in the j2se/make/sun/font >>build, >>>trying (of course) to build t2k.lib. The problem is, I can't figure out >>what >>>it's looking for in order to slip t2k.lib into the right place and move >>on. >>>Here's the results: >>> >>>CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font >>>$ make >>>/usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll >>>lib= ../../../build/windows-i586/bin/fontmanager.dll >>>make -C t2k >>>make[1]: Entering directory >>>`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' >>>make[1]: *** No rule to make target >>>`C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by >>>`../../../../build/windows-i586/libfiles/t2k.lib'. Stop. >>>make[1]: Leaving directory >>>`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' >>>make: *** [t2k] Error 2 >>> >>>Where did this directory "libfiles" come from in the build step? My >>guess is >>>it's coming from a variable/setting somewhere, but I can't figure out >>what >>>to set in order to help the build system find my cribbed t2k.lib so it >>can >>>move on. And even if I create said directories (both in the BinaryPlugs >>dir >>>and the build dir), and put t2k.lib in there, the build still fails. >>> >>>Help? >>> >>>BTW, in general, how does one debug the build process? 'make -d' just >>seems >>>horrendous.... >>> >>>Ted Neward >>>Java, .NET, XML Services >>>Consulting, Teaching, Speaking, Writing >>>http://www.tedneward.com >>> >>> >>>>-----Original Message----- >>>>From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >>>>bounces at openjdk.java.net] On Behalf Of Ted Neward >>>>Sent: Thursday, July 19, 2007 10:10 AM >>>>To: Phil.Race at Sun.COM >>>>Cc: build-dev at openjdk.java.net >>>>Subject: RE: T2K needed in Linux, also? >>>> >>>>Yep, had it pointing to the Import JDK (1.6) instead of the binary plug >>>>JDK >>>>(1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) >>>> >>>>By the way, in case those on this list haven't seen it, the build on >>Intel >>>>machines won't work, as there's a compilation error in a source file, >>as >>>>reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: >>>> >>>>#### >>>> >>>>--- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 >>>>10:29:14.412986944 -0700 >>>>+++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 >>>>10:29:31.499389416 -0700 >>>>@@ -158,7 +158,7 @@ >>>> >>>> // Easily misused constructor make them private #ifndef _LP64 >>>>- Address::Address(address loc, RelocationHolder spec); >>>>+ Address(address loc, RelocationHolder spec); >>>> #endif // _LP64 >>>> >>>> public: >>>> >>>>#### >>>> >>>>Peter Kessler reported it as already reported, a la >>>> >>>>http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html >>>> >>>>but no official bug had been filed, and there was some concern about >>>>Sunil's >>>>contributor status or whatnot. Not sure what happened to it from there. >>>> >>>>Ted Neward >>>>Java, .NET, XML Services >>>>Consulting, Teaching, Speaking, Writing >>>>http://www.tedneward.com >>>> >>>> >>>>>-----Original Message----- >>>>>From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] >>>>>Sent: Thursday, July 19, 2007 5:52 AM >>>>>To: Ted Neward >>>>>Cc: build-dev at openjdk.java.net >>>>>Subject: Re: T2K needed in Linux, also? >>>>> >>>>>Ted Neward wrote: >>>>>>When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a >>>>>>build error saying libt2k.so cannot be found. Am I missing something? >>>>>> >>>>>Yes, sounds like you are missing the entire binary plug download, or >>>>>haven't properly pointed to it's location. >>>>> >>>>>-phil. >>>>> >>>>>>Ted Neward >>>>>> >>>>>>Java, .NET, XML Services >>>>>> >>>>>>Consulting, Teaching, Speaking, Writing >>>>>> >>>>>>http://www.tedneward.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>No virus found in this outgoing message. >>>>>>Checked by AVG Free Edition. >>>>>>Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >>>>>>7/17/2007 6:30 PM >>>>>> >>>>>No virus found in this incoming message. >>>>>Checked by AVG Free Edition. >>>>>Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >>>>7/17/2007 >>>>>6:30 PM >>>>> >>>>No virus found in this outgoing message. >>>>Checked by AVG Free Edition. >>>>Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: >>7/18/2007 >>>>3:30 PM >>>> >>>> >>>>No virus found in this incoming message. >>>>Checked by AVG Free Edition. >>>>Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: >>7/18/2007 >>>>3:30 PM >>>> >>>No virus found in this outgoing message. >>>Checked by AVG Free Edition. >>>Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: >>7/24/2007 >>>1:50 PM >>> >>> >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007 >>2:55 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 > 3:50 PM > > From ted at tedneward.com Mon Jul 30 00:15:01 2007 From: ted at tedneward.com (Ted Neward) Date: Sun, 29 Jul 2007 17:15:01 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <46AD2B6F.3000305@sun.com> Message-ID: <08b801c7d23e$ad373430$802ca8c0@XPWork> Then maybe "clean" should be removed? It just seems that if you guys don't use it much, it's not all that useful, and therefore should just be struck as an option. (Besides, I always have a hard time determining the conceptual difference between "clean" and "clobber" anyway....) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Martin.Buchholz at Sun.COM [mailto:Martin.Buchholz at Sun.COM] > Sent: Sunday, July 29, 2007 5:06 PM > To: Ted Neward > Cc: Kelly.Ohair at Sun.COM; Phil.Race at Sun.COM; build-dev at openjdk.java.net > Subject: Re: T2K needed in Linux, also? > > I don't think JDK engineers do "make clean" very much. > They either do "make clobber", or the crude yet effective > > rm -rf ../build; make ... > > Martin > > Ted Neward wrote: > > Quick note: doing a "make clean" from the top yielded this: > > > > $ make clean > > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/outputdir > > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import > > ( cd ../../j2se/make; make clobber EXTERNALSANITYCONTROL=true > > MILESTONE=private > > BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-private-b00 > > ALT_OUTPUT > > DIR=c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > > ALT_HOTSPOT_IMPORT_PATH=c:/Prg > > /OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import > BUILD_HOTSPOT=true > > BUILD_ > > MOTIF=false ARCH_DATA_MODEL=32 ; ) > > make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > > ../make/common/shared/Defs-windows.gmk:611: "WARNING: Value of > > HOTSPOT_IMPORT_PA > > TH cannot be empty, check or set ALT_HOTSPOT_IMPORT_PATH" > > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > > rm: cannot remove directory > `c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1': > > Dir > > ectory not empty > > make[1]: *** [clobber] Error 1 > > make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > > make: *** [j2se-clobber] Error 2 > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > > $ > > > > Not sure if there was something in particular I needed to do to make the > > clean target work, but I "fixed" it by just nuking the build/* > directories > > by hand. However, this doesn't exactly work, as apparently "make clean" > > *creates* directories underneath build (build/windows-i586, in > particular) > > as part of cleaning the build. :-) > > > > I suspect this to be a bug, yes? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > >>-----Original Message----- > >>From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >>Sent: Saturday, July 28, 2007 2:15 PM > >>To: Ted Neward > >>Cc: Phil.Race at Sun.COM; build-dev at openjdk.java.net > >>Subject: Re: T2K needed in Linux, also? > >> > >>The new sparse binary plugs will have the same exact layout as a jdk > >>install > >>tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. > >>With one additional directory called "libfiles". This is where t2k.lib > >>will be found, > >>however, look quickly, because it may be deleted from the binary plugs > >>soon > >>and won't even be needed anymore. So anything you do around t2k.lib may > be > >>a bit > >>of a waste of time. The new sparse binary plugs are awaiting some legal > >>issues > >>and should be showing up any day now. > >> > >>The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with > >>the > >>binary plugs and has a rule that will copy the t2k.lib file into the > right > >>place when the make/sun/font/Makefile is run. There is an export and > >>import > >>process for the BinaryPlugs. As the different engineering groups remove > >>the need for plugs, this file should get smaller and smaller, as will > the > >>size of the binary plugs which will be created automatically soon. > >> > >>Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk > >>right > >>now: > >> > >>------- BinaryPlugs.gmk ------- > >>*** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 > >>--- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 > >>*************** > >>*** 448,453 **** > >>--- 448,454 ---- > >> import-binary-plug-t2k-library: \ > >> $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) > >> $(RM) $(OBJDIR)/t2k.lib > >>+ $(MKDIR) -p $(OBJDIR) > >> $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) > >> else # !windows > >> import-binary-plug-t2k-library: \ > >> > >>At least that's what we think prevents the new sparse binary plug > bundles > >>from allowing an OpenJDK build on windows to work right now. > >>We were testing windows builds last week just before I took off on a > >>short vacation. > >>You could simulate things by creating this "libfiles" directory and > >>placing > >>your t2k.lib file in it. > >> > >>As far as debugging the build process, it's not easy, but it has been > >>getting better over the last few releases. > >>Expect more build changes in the future with a goal of simplification. > >> > >>Try 'gnumake -p', or there was a recent article in Dr. Dobbs about > >>debugging > >>makefiles that was very helpful. Last month maybe or 2 months ago? > >> > >>-kto > >> > >> > >>Ted Neward wrote: > >>>Next issue: after an svn update (which caught me up to rev 244, the > >>latest > >>>in SVN), I do a Windows build, and it fails in the j2se/make/sun/font > >>build, > >>>trying (of course) to build t2k.lib. The problem is, I can't figure out > >>what > >>>it's looking for in order to slip t2k.lib into the right place and move > >>on. > >>>Here's the results: > >>> > >>>CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font > >>>$ make > >>>/usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll > >>>lib= ../../../build/windows-i586/bin/fontmanager.dll > >>>make -C t2k > >>>make[1]: Entering directory > >>>`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > >>>make[1]: *** No rule to make target > >>>`C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by > >>>`../../../../build/windows-i586/libfiles/t2k.lib'. Stop. > >>>make[1]: Leaving directory > >>>`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' > >>>make: *** [t2k] Error 2 > >>> > >>>Where did this directory "libfiles" come from in the build step? My > >>guess is > >>>it's coming from a variable/setting somewhere, but I can't figure out > >>what > >>>to set in order to help the build system find my cribbed t2k.lib so it > >>can > >>>move on. And even if I create said directories (both in the BinaryPlugs > >>dir > >>>and the build dir), and put t2k.lib in there, the build still fails. > >>> > >>>Help? > >>> > >>>BTW, in general, how does one debug the build process? 'make -d' just > >>seems > >>>horrendous.... > >>> > >>>Ted Neward > >>>Java, .NET, XML Services > >>>Consulting, Teaching, Speaking, Writing > >>>http://www.tedneward.com > >>> > >>> > >>>>-----Original Message----- > >>>>From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > >>>>bounces at openjdk.java.net] On Behalf Of Ted Neward > >>>>Sent: Thursday, July 19, 2007 10:10 AM > >>>>To: Phil.Race at Sun.COM > >>>>Cc: build-dev at openjdk.java.net > >>>>Subject: RE: T2K needed in Linux, also? > >>>> > >>>>Yep, had it pointing to the Import JDK (1.6) instead of the binary > plug > >>>>JDK > >>>>(1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) > >>>> > >>>>By the way, in case those on this list haven't seen it, the build on > >>Intel > >>>>machines won't work, as there's a compilation error in a source file, > >>as > >>>>reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: > >>>> > >>>>#### > >>>> > >>>>--- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 > >>>>10:29:14.412986944 -0700 > >>>>+++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 > >>>>10:29:31.499389416 -0700 > >>>>@@ -158,7 +158,7 @@ > >>>> > >>>> // Easily misused constructor make them private #ifndef _LP64 > >>>>- Address::Address(address loc, RelocationHolder spec); > >>>>+ Address(address loc, RelocationHolder spec); > >>>> #endif // _LP64 > >>>> > >>>> public: > >>>> > >>>>#### > >>>> > >>>>Peter Kessler reported it as already reported, a la > >>>> > >>>>http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html > >>>> > >>>>but no official bug had been filed, and there was some concern about > >>>>Sunil's > >>>>contributor status or whatnot. Not sure what happened to it from > there. > >>>> > >>>>Ted Neward > >>>>Java, .NET, XML Services > >>>>Consulting, Teaching, Speaking, Writing > >>>>http://www.tedneward.com > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > >>>>>Sent: Thursday, July 19, 2007 5:52 AM > >>>>>To: Ted Neward > >>>>>Cc: build-dev at openjdk.java.net > >>>>>Subject: Re: T2K needed in Linux, also? > >>>>> > >>>>>Ted Neward wrote: > >>>>>>When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a > >>>>>>build error saying libt2k.so cannot be found. Am I missing > something? > >>>>>> > >>>>>Yes, sounds like you are missing the entire binary plug download, or > >>>>>haven't properly pointed to it's location. > >>>>> > >>>>>-phil. > >>>>> > >>>>>>Ted Neward > >>>>>> > >>>>>>Java, .NET, XML Services > >>>>>> > >>>>>>Consulting, Teaching, Speaking, Writing > >>>>>> > >>>>>>http://www.tedneward.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>No virus found in this outgoing message. > >>>>>>Checked by AVG Free Edition. > >>>>>>Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >>>>>>7/17/2007 6:30 PM > >>>>>> > >>>>>No virus found in this incoming message. > >>>>>Checked by AVG Free Edition. > >>>>>Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: > >>>>7/17/2007 > >>>>>6:30 PM > >>>>> > >>>>No virus found in this outgoing message. > >>>>Checked by AVG Free Edition. > >>>>Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > >>7/18/2007 > >>>>3:30 PM > >>>> > >>>> > >>>>No virus found in this incoming message. > >>>>Checked by AVG Free Edition. > >>>>Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: > >>7/18/2007 > >>>>3:30 PM > >>>> > >>>No virus found in this outgoing message. > >>>Checked by AVG Free Edition. > >>>Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: > >>7/24/2007 > >>>1:50 PM > >>> > >>> > >>No virus found in this incoming message. > >>Checked by AVG Free Edition. > >>Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: > 7/25/2007 > >>2:55 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > 7/28/2007 > > 3:50 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 > 3:50 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM From Tim.Bell at Sun.COM Mon Jul 30 00:22:11 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sun, 29 Jul 2007 17:22:11 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <46AD2B6F.3000305@sun.com> References: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> <46AD2B6F.3000305@sun.com> Message-ID: <46AD2F33.9090209@sun.com> Martin Buchholz wrote: > I don't think JDK engineers do "make clean" very much. > They either do "make clobber", or the crude yet effective > > rm -rf ../build; make ... Actually, if you are in a hurry (and who isn't :-) it is faster to 'mv build build.00; make ...' At the end of the day, or whenever free disk space runs low, delete all the old build.nn directories, or schedule a cron job.... Tim From Kelly.Ohair at Sun.COM Mon Jul 30 03:00:10 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 29 Jul 2007 20:00:10 -0700 Subject: T2K needed in Linux, also? In-Reply-To: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> References: <08ae01c7d23c$c7d03410$802ca8c0@XPWork> Message-ID: <46AD543A.6090704@sun.com> As far as I'm concerned clean==clobber. It used to be that one of these would also trigger a 'sccs clean', which is pretty insane in my opinion when you are talking about 30,000 files. So usually a 'make clean' does the same thing as 'make clobber'. On windows the 'rm -f -r' failing usually means that there is a permission problem, or some process or window is still using something in this directory, OR somehow one of the files in this directory exceeds some small length limit of windows (254?). With windows there are lots of reasons. The trick of 'mv build build.NNN' may not work on windows. The only reliable way to deal with this on windows is to always create a unique directory from the beginning, with a time stamp in the name or something. Which is a pain. There is a bug here, but it's tricky. There are some Makefile lines like: dummy := $(shell $(MKDIR) $(OUTPUTDIR)) that are used to force the creation of the output directory, I suspect this is the cause of the problem, and I suspect this is mostly a windows problem. But they were put there for a good reason, so removing them may mean figuring out why they were needed and finding another solution. Part of this may be buried in the windows short pathnames logic, e.g. CYGWIN's 'cygpath -s' or MKS's 'dosname -s'. In order for you to find the short non-space path on windows, it needs to exist first, if it exists and you remove it and then re-create it, the short pathname changes. On control builds, I normally just 'rm -f -r build' to clean it. -kto Ted Neward wrote: > Quick note: doing a "make clean" from the top yielded this: > > $ make clean > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/outputdir > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import > ( cd ../../j2se/make; make clobber EXTERNALSANITYCONTROL=true > MILESTONE=private > BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-private-b00 > ALT_OUTPUT > DIR=c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > ALT_HOTSPOT_IMPORT_PATH=c:/Prg > /OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import BUILD_HOTSPOT=true > BUILD_ > MOTIF=false ARCH_DATA_MODEL=32 ; ) > make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > ../make/common/shared/Defs-windows.gmk:611: "WARNING: Value of > HOTSPOT_IMPORT_PA > TH cannot be empty, check or set ALT_HOTSPOT_IMPORT_PATH" > rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1 > rm: cannot remove directory `c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1': > Dir > ectory not empty > make[1]: *** [clobber] Error 1 > make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > make: *** [j2se-clobber] Error 2 > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > $ > > Not sure if there was something in particular I needed to do to make the > clean target work, but I "fixed" it by just nuking the build/* directories > by hand. However, this doesn't exactly work, as apparently "make clean" > *creates* directories underneath build (build/windows-i586, in particular) > as part of cleaning the build. :-) > > I suspect this to be a bug, yes? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Saturday, July 28, 2007 2:15 PM >> To: Ted Neward >> Cc: Phil.Race at Sun.COM; build-dev at openjdk.java.net >> Subject: Re: T2K needed in Linux, also? >> >> The new sparse binary plugs will have the same exact layout as a jdk >> install >> tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc. >> With one additional directory called "libfiles". This is where t2k.lib >> will be found, >> however, look quickly, because it may be deleted from the binary plugs >> soon >> and won't even be needed anymore. So anything you do around t2k.lib may be >> a bit >> of a waste of time. The new sparse binary plugs are awaiting some legal >> issues >> and should be showing up any day now. >> >> The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with >> the >> binary plugs and has a rule that will copy the t2k.lib file into the right >> place when the make/sun/font/Makefile is run. There is an export and >> import >> process for the BinaryPlugs. As the different engineering groups remove >> the need for plugs, this file should get smaller and smaller, as will the >> size of the binary plugs which will be created automatically soon. >> >> Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk >> right >> now: >> >> ------- BinaryPlugs.gmk ------- >> *** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007 >> --- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007 >> *************** >> *** 448,453 **** >> --- 448,454 ---- >> import-binary-plug-t2k-library: \ >> $(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY) >> $(RM) $(OBJDIR)/t2k.lib >> + $(MKDIR) -p $(OBJDIR) >> $(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR) >> else # !windows >> import-binary-plug-t2k-library: \ >> >> At least that's what we think prevents the new sparse binary plug bundles >> from allowing an OpenJDK build on windows to work right now. >> We were testing windows builds last week just before I took off on a >> short vacation. >> You could simulate things by creating this "libfiles" directory and >> placing >> your t2k.lib file in it. >> >> As far as debugging the build process, it's not easy, but it has been >> getting better over the last few releases. >> Expect more build changes in the future with a goal of simplification. >> >> Try 'gnumake -p', or there was a recent article in Dr. Dobbs about >> debugging >> makefiles that was very helpful. Last month maybe or 2 months ago? >> >> -kto >> >> >> Ted Neward wrote: >>> Next issue: after an svn update (which caught me up to rev 244, the >> latest >>> in SVN), I do a Windows build, and it fails in the j2se/make/sun/font >> build, >>> trying (of course) to build t2k.lib. The problem is, I can't figure out >> what >>> it's looking for in order to slip t2k.lib into the right place and move >> on. >>> Here's the results: >>> >>> CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font >>> $ make >>> /usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll >>> lib= ../../../build/windows-i586/bin/fontmanager.dll >>> make -C t2k >>> make[1]: Entering directory >>> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' >>> make[1]: *** No rule to make target >>> `C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by >>> `../../../../build/windows-i586/libfiles/t2k.lib'. Stop. >>> make[1]: Leaving directory >>> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k' >>> make: *** [t2k] Error 2 >>> >>> Where did this directory "libfiles" come from in the build step? My >> guess is >>> it's coming from a variable/setting somewhere, but I can't figure out >> what >>> to set in order to help the build system find my cribbed t2k.lib so it >> can >>> move on. And even if I create said directories (both in the BinaryPlugs >> dir >>> and the build dir), and put t2k.lib in there, the build still fails. >>> >>> Help? >>> >>> BTW, in general, how does one debug the build process? 'make -d' just >> seems >>> horrendous.... >>> >>> Ted Neward >>> Java, .NET, XML Services >>> Consulting, Teaching, Speaking, Writing >>> http://www.tedneward.com >>> >>> >>>> -----Original Message----- >>>> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >>>> bounces at openjdk.java.net] On Behalf Of Ted Neward >>>> Sent: Thursday, July 19, 2007 10:10 AM >>>> To: Phil.Race at Sun.COM >>>> Cc: build-dev at openjdk.java.net >>>> Subject: RE: T2K needed in Linux, also? >>>> >>>> Yep, had it pointing to the Import JDK (1.6) instead of the binary plug >>>> JDK >>>> (1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-) >>>> >>>> By the way, in case those on this list haven't seen it, the build on >> Intel >>>> machines won't work, as there's a compilation error in a source file, >> as >>>> reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch: >>>> >>>> #### >>>> >>>> --- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09 >>>> 10:29:14.412986944 -0700 >>>> +++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09 >>>> 10:29:31.499389416 -0700 >>>> @@ -158,7 +158,7 @@ >>>> >>>> // Easily misused constructor make them private #ifndef _LP64 >>>> - Address::Address(address loc, RelocationHolder spec); >>>> + Address(address loc, RelocationHolder spec); >>>> #endif // _LP64 >>>> >>>> public: >>>> >>>> #### >>>> >>>> Peter Kessler reported it as already reported, a la >>>> >>>> http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html >>>> >>>> but no official bug had been filed, and there was some concern about >>>> Sunil's >>>> contributor status or whatnot. Not sure what happened to it from there. >>>> >>>> Ted Neward >>>> Java, .NET, XML Services >>>> Consulting, Teaching, Speaking, Writing >>>> http://www.tedneward.com >>>> >>>> >>>>> -----Original Message----- >>>>> From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] >>>>> Sent: Thursday, July 19, 2007 5:52 AM >>>>> To: Ted Neward >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: T2K needed in Linux, also? >>>>> >>>>> Ted Neward wrote: >>>>>> When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a >>>>>> build error saying libt2k.so cannot be found. Am I missing something? >>>>>> >>>>> Yes, sounds like you are missing the entire binary plug download, or >>>>> haven't properly pointed to it's location. >>>>> >>>>> -phil. >>>>> >>>>>> Ted Neward >>>>>> >>>>>> Java, .NET, XML Services >>>>>> >>>>>> Consulting, Teaching, Speaking, Writing >>>>>> >>>>>> http://www.tedneward.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> No virus found in this outgoing message. >>>>>> Checked by AVG Free Edition. >>>>>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >>>>>> 7/17/2007 6:30 PM >>>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG Free Edition. >>>>> Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: >>>> 7/17/2007 >>>>> 6:30 PM >>>>> >>>> No virus found in this outgoing message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: >> 7/18/2007 >>>> 3:30 PM >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: >> 7/18/2007 >>>> 3:30 PM >>>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: >> 7/24/2007 >>> 1:50 PM >>> >>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007 >> 2:55 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 > 3:50 PM > > From ted at tedneward.com Mon Jul 30 08:43:17 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 30 Jul 2007 01:43:17 -0700 Subject: New bug in build process Message-ID: <095701c7d285$b92cc1f0$802ca8c0@XPWork> After doing a ?nuke? of the build dir, and doing a fresh ?make debug_build DEV=1? (again, on Windows), I get this: Creating library c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo nt/fontmanager/obj_gO/fontmanager.lib and object c:/Prg/OpenJDK/openjdk/control/ build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs reference d in function _Java_sun_font_FontManager_initIDs at 8 sunFont.obj : error LNK2019: unresolved external symbol _isNullScalerContext ref erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 SunLayoutEngine.obj : error LNK2019: unresolved external symbol _getUnitsPerEmFo rLayout referenced in function "public: virtual long __thiscall FontInstanceAdap ter::getUnitsPerEM(void)const " (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) FontInstanceAdapter.obj : error LNK2001: unresolved external symbol _getUnitsPer EmForLayout FontInstanceAdapter.obj : error LNK2019: unresolved external symbol _getLayoutTa bles referenced in function "public: __thiscall FontInstanceAdapter::FontInstanc eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float *,long,long)" (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager/o bj_g O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals make[5]: *** [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] Error 96 make[5]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' make[4]: *** [all] Error 1 make[4]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' make[3]: *** [all] Error 1 make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' make[2]: *** [j2se-build] Error 2 make[2]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' make[1]: *** [generic_debug_build] Error 2 make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' make: *** [fastdebug_build] Error 2 CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make $ Apparently there?s some missing object files in the link step of fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related again, since we?re back in the silly font directory again, and yes, I know, t2k is going away soon, but I?d like to see if it can be worked around in the meantime. Legal issues have this annoying tendency to take MUCH longer than engineers think they should? :-) The build output prior to this link line is pretty verbose, but I can send it if it?ll help debug the problem?. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kelly.Ohair at Sun.COM Mon Jul 30 14:01:55 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 30 Jul 2007 07:01:55 -0700 Subject: New bug in build process In-Reply-To: <095701c7d285$b92cc1f0$802ca8c0@XPWork> References: <095701c7d285$b92cc1f0$802ca8c0@XPWork> Message-ID: <46ADEF53.2040304@sun.com> Is this t2k.lib file the one you created from t2k.dll? I've never seen these errors before, but it looks like it's in the fastdebug build, which would mean you got past the product build, which is significant. This is just a wild guess, but I wonder if the debug t2k.dll file has more external symbols than the product one? I'm not that familiar with the external list for this library. --- Keep in mind that although we regularly build the fastdebug bits (-g -O), and some developers build the debug bits (-g), neither are tested very extensively. With the exception of the Hotspot VM, which gets tested fairly well with VM type tests. It's the product built bits that get most of the formal JDK testing done to them. Product .obj/.o files should end up in a obj directory (under build/*/tmp), fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are seeing some obj_gO references and some obj_g references. Maybe there is another bug in the BinaryPlugs.gmk file... :^( -kto Ted Neward wrote: > After doing a ?nuke? of the build dir, and doing a fresh ?make > debug_build DEV=1? (again, on Windows), I get this: > > > > Creating library > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo > > nt/fontmanager/obj_gO/fontmanager.lib and object > c:/Prg/OpenJDK/openjdk/control/ > > build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp > > sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs > reference > > d in function _Java_sun_font_FontManager_initIDs at 8 > > sunFont.obj : error LNK2019: unresolved external symbol > _isNullScalerContext ref > > erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 > > SunLayoutEngine.obj : error LNK2019: unresolved external symbol > _getUnitsPerEmFo > > rLayout referenced in function "public: virtual long __thiscall > FontInstanceAdap > > ter::getUnitsPerEM(void)const " (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) > > FontInstanceAdapter.obj : error LNK2001: unresolved external symbol > _getUnitsPer > > EmForLayout > > FontInstanceAdapter.obj : error LNK2019: unresolved external symbol > _getLayoutTa > > bles referenced in function "public: __thiscall > FontInstanceAdapter::FontInstanc > > eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float > *,long,long)" > > (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) > > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_g > > O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals > > make[5]: *** > [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] > > Error 96 > > make[5]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' > > make[4]: *** [all] Error 1 > > make[4]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' > > make[3]: *** [all] Error 1 > > make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > > make[2]: *** [j2se-build] Error 2 > > make[2]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > make[1]: *** [generic_debug_build] Error 2 > > make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > make: *** [fastdebug_build] Error 2 > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > > $ > > > > Apparently there?s some missing object files in the link step of > fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related > again, since we?re back in the silly font directory again, and yes, I > know, t2k is going away soon, but I?d like to see if it can be worked > around in the meantime. Legal issues have this annoying tendency to take > MUCH longer than engineers think they should? :-) > > > > The build output prior to this link line is pretty verbose, but I can > send it if it?ll help debug the problem?. > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > 7/28/2007 3:50 PM > From Kelly.Ohair at Sun.COM Mon Jul 30 16:29:04 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 30 Jul 2007 09:29:04 -0700 Subject: A little progress report on Mercurial and build/source infrastructure changes Message-ID: <46AE11D0.6040709@sun.com> Re: A little progress report on Mercurial and build/source infrastructure changes I thought I would take some time to list a few of the up and coming changes with regards to Open JDK builds and source structure. I don't want anyone blogging that we are keeping secrets from everyone. ;^) We are converting OpenJDK to Mercurial but it's taking longer than I had planned. There is a long list of issues we are trying to clear up internally, some in the area of the keeping the legal eagles happy, and others just major cleanups we want to do before starting out in a fresh new world of Mercurial. We have used TeamWare for over 10 years (or longer?), so internally this is a huge change for the JDK developers, and the fact that we will be externally exposing our Mercurial repositories makes us nervous and very careful. To anyone downloading source bundles, this impact should be minimal, but the Mercurial conversion will cause many files to get moved around. In the process of converting to Mercurial there will also be some basic build infrastructure changes. So fair warning, things will be changing. Internally we deal with many TeamWare workspaces, the big 2 primary ones have historically been j2se and hotspot. These 2 workspaces do contain some of what we are calling "closed" sources. The goal is to minimize these closed parts of the workspaces, either by opening these files up where possible, or replacing them. That will take time and will happen over the long term, perhaps faster once we get public Mercurial repositories out in the open. The current plan is that we would continue to keep components like hotspot in a separate repository, and we are currently looking at separating out parts of the existing j2se workspace into new repositories where it makes sense. You may see a "langtools" repository that contains just javac/javah/javadoc/apt, and you may see an "ee" repository that contains much of the Java EE contribution to the OpenJDK. These two have been chosen because they are large chunks of the j2se files that get delivered to more than just the JDK, and can be built and run with just the BOOTJDK (no dependence on JDK7 apis or a running JDK7). The build procedure becomes much simplier once the "langtools" get separated out. e.g. (just a prediction) 1. Build langtools with BOOTJDK 2. Build hotspot with langtools javac and BOOTJDK and C/C++ compilers 3. Build ee with langtools javac and BOOTJDK 4. Build the rest of the j2se with ee, hotspot, langtools javac and BOOTJDK and C/C++ compilers 5. Repeat 1-4 with this new JDK7 (which hasn't run yet) as the BOOTJDK In step 4 one of the big changes will be that we won't need to run what we are building as it happens now, that would be done in step 5. This should make cross development easier, and certainly simplifies the build process from my perspective. The "rest of j2se" and the current "control" files may become the primary "jdk" repository, and the hotspot, langtools, and ee repositories may be nested inside this jdk repository as nested repositories (TeamWare doesn't allow nesting, but Mercurial does). Each repository should be rather independent in terms of developers. Many people have suggested breaking up the j2se even further, but we won't be doing that initially. There are some serious issues with regards to the JDK7 runtime dependencies that needs to be taken into account with each separated component. Don't expect this to happen overnight, the current internal transition to Mercurial is scheduled for roughly Oct2007, and our dates have slipped once already. We have made great progress on the "langtools" separation and are now getting started on the "ee" separation. Many other smaller to medium sized details remain to be dealt with, but we are progressing. I hope this helps explain the current state. Now back to work. ;^) -kto From ted at tedneward.com Tue Jul 31 04:42:29 2007 From: ted at tedneward.com (Ted Neward) Date: Mon, 30 Jul 2007 21:42:29 -0700 Subject: New bug in build process In-Reply-To: <46ADEF53.2040304@sun.com> Message-ID: <0c2e01c7d32d$37e19c30$802ca8c0@XPWork> > Is this t2k.lib file the one you created from t2k.dll? > Yes. > I've never seen these errors before, but it looks like it's in the > fastdebug build, which would mean you got past the product build, > which is significant. > Unfortunately, no, that's not the case--I was doing a fastdebug build explicitly (make fastdebug_build DEV=1). > Keep in mind that although we regularly build the fastdebug bits (-g -O), > and > some developers build the debug bits (-g), neither are tested very > extensively. > With the exception of the Hotspot VM, which gets tested fairly well with > VM type tests. > It's the product built bits that get most of the formal JDK testing done > to them. > I'm primarily interested in the debug builds because then I have symbols and can do a lot better exploratory spelunking in tools like debuggers. Besides, as I spelunk, I'll want to make some source changes (just to play around or display information), and a lot more info is present in debug builds than product builds. Frankly, just getting a fastdebug build to go from start to finish would probably be sufficient. Actually, just having fastdebug Hotspot is really sufficient for what I want to play around with, but I figure while I'm here I'll try to help debug the Windows build process if I can. :-) > Product .obj/.o files should end up in a obj directory (under > build/*/tmp), > fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are > seeing > some obj_gO references and some obj_g references. Maybe there is another > bug in > the BinaryPlugs.gmk file... :^( > Let me start over and do a fresh build, capture the results (is there a good way to capture the complete build output?), and send them to you. What "make" command should I use? "make all DEV=1"? Something else? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Monday, July 30, 2007 7:02 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: New bug in build process > > Is this t2k.lib file the one you created from t2k.dll? > > I've never seen these errors before, but it looks like it's in the > fastdebug build, which would mean you got past the product build, > which is significant. > > This is just a wild guess, but I wonder if the debug t2k.dll file has more > external symbols than the product one? I'm not that familiar with > the external list for this library. > > --- > > Keep in mind that although we regularly build the fastdebug bits (-g -O), > and > some developers build the debug bits (-g), neither are tested very > extensively. > With the exception of the Hotspot VM, which gets tested fairly well with > VM type tests. > It's the product built bits that get most of the formal JDK testing done > to them. > > Product .obj/.o files should end up in a obj directory (under > build/*/tmp), > fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are > seeing > some obj_gO references and some obj_g references. Maybe there is another > bug in > the BinaryPlugs.gmk file... :^( > > -kto > > Ted Neward wrote: > > After doing a ?nuke? of the build dir, and doing a fresh ?make > > debug_build DEV=1? (again, on Windows), I get this: > > > > > > > > Creating library > > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo > > > > nt/fontmanager/obj_gO/fontmanager.lib and object > > c:/Prg/OpenJDK/openjdk/control/ > > > > build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp > > > > sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs > > reference > > > > d in function _Java_sun_font_FontManager_initIDs at 8 > > > > sunFont.obj : error LNK2019: unresolved external symbol > > _isNullScalerContext ref > > > > erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 > > > > SunLayoutEngine.obj : error LNK2019: unresolved external symbol > > _getUnitsPerEmFo > > > > rLayout referenced in function "public: virtual long __thiscall > > FontInstanceAdap > > > > ter::getUnitsPerEM(void)const " > (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) > > > > FontInstanceAdapter.obj : error LNK2001: unresolved external symbol > > _getUnitsPer > > > > EmForLayout > > > > FontInstanceAdapter.obj : error LNK2019: unresolved external symbol > > _getLayoutTa > > > > bles referenced in function "public: __thiscall > > FontInstanceAdapter::FontInstanc > > > > eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float > > *,long,long)" > > > > (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) > > > > > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager > /obj_g > > > > O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals > > > > make[5]: *** > > [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] > > > > Error 96 > > > > make[5]: Leaving directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' > > > > make[4]: *** [all] Error 1 > > > > make[4]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' > > > > make[3]: *** [all] Error 1 > > > > make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > > > > make[2]: *** [j2se-build] Error 2 > > > > make[2]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > > > make[1]: *** [generic_debug_build] Error 2 > > > > make[1]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > > > make: *** [fastdebug_build] Error 2 > > > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > > > > $ > > > > > > > > Apparently there?s some missing object files in the link step of > > fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related > > again, since we?re back in the silly font directory again, and yes, I > > know, t2k is going away soon, but I?d like to see if it can be worked > > around in the meantime. Legal issues have this annoying tendency to take > > MUCH longer than engineers think they should? :-) > > > > > > > > The build output prior to this link line is pretty verbose, but I can > > send it if it?ll help debug the problem?. > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > > 7/28/2007 3:50 PM > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 > 3:50 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 3:50 PM From Phil.Race at Sun.COM Tue Jul 31 21:39:19 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 31 Jul 2007 14:39:19 -0700 Subject: encumbrances update Message-ID: <46AFAC07.6060608@sun.com> I just want to give a quick update on the state of one the 2D encumbrances to a broader audience than the 2D and font mailing lists, since the state of encumbrances are generally of broad interest. Igor Nekrestyanov just put back into what will be b17 the first version of the code that replaces using the T2K font rasteriser with freetype. This should be be out on openjdk.java.net in a few days. It is believed to build and work on all platform combinations : windows, linux, solaris, 32 and 64 bit, but testing has focused on the 32 bit versions. Whilst removing the encumbrance, it does add the requirement that you have freetype around. That is, at this time, we chose not to include sources for a specific freetype since we think most distros will want to link against the platform one. If the build detects a compatible freetype in /usr/lib it will just link against that. But if needed you can provide your own by setting ALT_FREETYPE_LIB_PATH, in which case ALT_FREETYPE_HEADERS_PATH should also be set. The build docs have been updated with this information. We have only tested against recent freetypes : 2.3.0 and later. So there's some work to do there to see what the actual minimum requirements are. If you have an earlier version you want to try, you may need to bypass the sanity check. Please try it out, and let us know of any suggestions for improvement etc by communicating on http://mail.openjdk.java.net/mailman/listinfo/font-scaler-dev And on a related note, Alexey Menkov is making changes which separate out the encumbered Java Sound code from the unemcumbered parts. This basically slims down the binary plug to just those parts that need to be in it, making it easier to replace. Hopefully that will be in an openjdk drop in about two weeks. I expect Alexey have more to say on this on the sound mailing lists : http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev http://mail.openjdk.java.net/pipermail/sound-dev/ -Phil. From ted at tedneward.com Tue Jul 31 21:56:21 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 31 Jul 2007 14:56:21 -0700 Subject: New bug in build process In-Reply-To: <46ADEF53.2040304@sun.com> Message-ID: <0f8101c7d3bd$a6a2df40$802ca8c0@XPWork> I think the problem may be more subtle than this; I did a little investigation, and missing functions are present in T2K.DLL, but not with the leading underscores. I took a look at the exports from T2K.DLL, and they're as follows: C:\Prg\OpenJDK\BinaryPlugs>dumpbin /exports jdk1.7.0\jre\bin\t2k.dll Microsoft (R) COFF/PE Dumper Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file jdk1.7.0\jre\bin\t2k.dll File Type: DLL Section contains the following exports for t2k.dll 00000000 characteristics 468CC934 time date stamp Thu Jul 05 03:34:28 2007 0.00 version 1 ordinal base 22 number of functions 22 number of names ordinal hint RVA name 1 0 0002306C _Java_sun_font_FileFontStrike_createScalerContext at 44 2 1 0002302E _Java_sun_font_FileFontStrike_getNullScalerContext at 16 3 2 00023F9F _Java_sun_font_FileFont_freeScaler at 16 4 3 00024762 _Java_sun_font_FileFont_getFontMetrics at 16 5 4 00024027 _Java_sun_font_FileFont_getGlyphAdvance at 20 6 5 0002428C _Java_sun_font_FileFont_getGlyphImage at 20 7 6 00024108 _Java_sun_font_FileFont_getGlyphMetrics at 24 8 7 00025275 _Java_sun_font_FileFont_getGlyphOutline at 28 9 8 000252CC _Java_sun_font_FileFont_getGlyphOutlineBounds at 20 10 9 00025321 _Java_sun_font_FileFont_getGlyphVectorOutline at 32 11 A 00022EE1 _Java_sun_font_FileFont_getNullScaler at 8 12 B 00023D91 _Java_sun_font_FileFont_setNullScaler at 16 13 C 000233A7 _Java_sun_font_TrueTypeFont_createScaler at 24 14 D 0002463E _Java_sun_font_TrueTypeFont_getGlyphPoint at 24 15 E 00022EEB _Java_sun_font_Type1Font_createScaler at 12 16 F 00023F13 _Java_sun_font_Type1Font_getGlyphCode at 20 17 10 00023EF8 _Java_sun_font_Type1Font_getMissingGlyphCode at 16 18 11 00023EDB _Java_sun_font_Type1Font_getNumGlyphs at 16 19 12 00023E20 getLayoutTables 20 13 00023DBD getUnitsPerEmForLayout 21 14 00023055 isNullScalerContext 22 15 00022C03 setSunFontIDs Summary 1000 .data 7000 .rdata 2000 .reloc 1000 .rsrc 25000 .text As you can see, those missing four functions *are* there, in T2K.dll, but don't have the leading underscore, which somehow the compiler thinks is there. My guess is that there's a calling convention mixup here somehow, or else the T2K.lib is somehow written to insert the leading underscores there. (Which then implies it's not just a straightforward import library, I think.) Is it possible that there's a macro somewhere in the native code that's inserting an underscore when it shouldn't? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Monday, July 30, 2007 7:02 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: New bug in build process > > Is this t2k.lib file the one you created from t2k.dll? > > I've never seen these errors before, but it looks like it's in the > fastdebug build, which would mean you got past the product build, > which is significant. > > This is just a wild guess, but I wonder if the debug t2k.dll file has more > external symbols than the product one? I'm not that familiar with > the external list for this library. > > --- > > Keep in mind that although we regularly build the fastdebug bits (-g -O), > and > some developers build the debug bits (-g), neither are tested very > extensively. > With the exception of the Hotspot VM, which gets tested fairly well with > VM type tests. > It's the product built bits that get most of the formal JDK testing done > to them. > > Product .obj/.o files should end up in a obj directory (under > build/*/tmp), > fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are > seeing > some obj_gO references and some obj_g references. Maybe there is another > bug in > the BinaryPlugs.gmk file... :^( > > -kto > > Ted Neward wrote: > > After doing a ?nuke? of the build dir, and doing a fresh ?make > > debug_build DEV=1? (again, on Windows), I get this: > > > > > > > > Creating library > > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo > > > > nt/fontmanager/obj_gO/fontmanager.lib and object > > c:/Prg/OpenJDK/openjdk/control/ > > > > build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp > > > > sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs > > reference > > > > d in function _Java_sun_font_FontManager_initIDs at 8 > > > > sunFont.obj : error LNK2019: unresolved external symbol > > _isNullScalerContext ref > > > > erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 > > > > SunLayoutEngine.obj : error LNK2019: unresolved external symbol > > _getUnitsPerEmFo > > > > rLayout referenced in function "public: virtual long __thiscall > > FontInstanceAdap > > > > ter::getUnitsPerEM(void)const " > (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) > > > > FontInstanceAdapter.obj : error LNK2001: unresolved external symbol > > _getUnitsPer > > > > EmForLayout > > > > FontInstanceAdapter.obj : error LNK2019: unresolved external symbol > > _getLayoutTa > > > > bles referenced in function "public: __thiscall > > FontInstanceAdapter::FontInstanc > > > > eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float > > *,long,long)" > > > > (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) > > > > > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager > /obj_g > > > > O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals > > > > make[5]: *** > > [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] > > > > Error 96 > > > > make[5]: Leaving directory > > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' > > > > make[4]: *** [all] Error 1 > > > > make[4]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' > > > > make[3]: *** [all] Error 1 > > > > make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > > > > make[2]: *** [j2se-build] Error 2 > > > > make[2]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > > > make[1]: *** [generic_debug_build] Error 2 > > > > make[1]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > > > > make: *** [fastdebug_build] Error 2 > > > > CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > > > > $ > > > > > > > > Apparently there?s some missing object files in the link step of > > fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related > > again, since we?re back in the silly font directory again, and yes, I > > know, t2k is going away soon, but I?d like to see if it can be worked > > around in the meantime. Legal issues have this annoying tendency to take > > MUCH longer than engineers think they should? :-) > > > > > > > > The build output prior to this link line is pretty verbose, but I can > > send it if it?ll help debug the problem?. > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > > 7/28/2007 3:50 PM > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 > 3:50 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 5:26 PM From ted at tedneward.com Tue Jul 31 22:09:07 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 31 Jul 2007 15:09:07 -0700 Subject: encumbrances update In-Reply-To: <46AFAC07.6060608@sun.com> Message-ID: <100701c7d3bf$71789290$802ca8c0@XPWork> Is that code in SVN now? Can you send a quick email to this list when it does go in, if it's not already? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Phil Race > Sent: Tuesday, July 31, 2007 2:39 PM > To: build-dev at openjdk.java.net; discuss at openjdk.java.net > Subject: encumbrances update > > > I just want to give a quick update on the state of one the 2D encumbrances > to a broader audience than the 2D and font mailing lists, since the > state of encumbrances are generally of broad interest. > > Igor Nekrestyanov just put back into what will be b17 the first version of > the > code that replaces using the T2K font rasteriser with freetype. > This should be be out on openjdk.java.net in a few days. > > It is believed to build and work on all platform combinations : windows, > linux, solaris, 32 and 64 bit, but testing has focused on the 32 bit > versions. > > Whilst removing the encumbrance, it does add the requirement > that you have freetype around. That is, at this time, we > chose not to include sources for a specific freetype since > we think most distros will want to link against the platform one. > > If the build detects a compatible freetype in /usr/lib it will > just link against that. > > But if needed you can provide your own by setting ALT_FREETYPE_LIB_PATH, > in which case ALT_FREETYPE_HEADERS_PATH should also be set. > The build docs have been updated with this information. > > We have only tested against recent freetypes : 2.3.0 and later. > So there's some work to do there to see what the actual minimum > requirements are. If you have an earlier version you want to > try, you may need to bypass the sanity check. > > Please try it out, and let us know of any suggestions for > improvement etc by communicating on > http://mail.openjdk.java.net/mailman/listinfo/font-scaler-dev > > And on a related note, Alexey Menkov is making changes which > separate out the encumbered Java Sound code from the unemcumbered parts. > This basically slims down the binary plug to just those parts that > need to be in it, making it easier to replace. Hopefully that > will be in an openjdk drop in about two weeks. I expect Alexey > have more to say on this on the sound mailing lists : > http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev > http://mail.openjdk.java.net/pipermail/sound-dev/ > > -Phil. > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 > 5:26 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 5:26 PM From Phil.Race at Sun.COM Tue Jul 31 22:19:35 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 31 Jul 2007 15:19:35 -0700 Subject: New bug in build process In-Reply-To: <0f8101c7d3bd$a6a2df40$802ca8c0@XPWork> References: <0f8101c7d3bd$a6a2df40$802ca8c0@XPWork> Message-ID: <46AFB577.2060302@sun.com> Ted, the code for those methods is (in b16) in src/share/native/sun/font/scalerMethods.c so you can see for yourself there's nothing special about them except that the rest are JNI methods and they aren't : they are called directly from fontmanager.dll so if they weren't exported properly we'd know about it .. Anyway this will all be moot in a few days when b17 is out. -phil. Ted Neward wrote: > I think the problem may be more subtle than this; I did a little > investigation, and missing functions are present in T2K.DLL, but not with > the leading underscores. I took a look at the exports from T2K.DLL, and > they're as follows: > > C:\Prg\OpenJDK\BinaryPlugs>dumpbin /exports jdk1.7.0\jre\bin\t2k.dll > Microsoft (R) COFF/PE Dumper Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > > Dump of file jdk1.7.0\jre\bin\t2k.dll > > File Type: DLL > > Section contains the following exports for t2k.dll > > 00000000 characteristics > 468CC934 time date stamp Thu Jul 05 03:34:28 2007 > 0.00 version > 1 ordinal base > 22 number of functions > 22 number of names > > ordinal hint RVA name > > 1 0 0002306C > _Java_sun_font_FileFontStrike_createScalerContext at 44 > 2 1 0002302E > _Java_sun_font_FileFontStrike_getNullScalerContext at 16 > 3 2 00023F9F _Java_sun_font_FileFont_freeScaler at 16 > 4 3 00024762 _Java_sun_font_FileFont_getFontMetrics at 16 > 5 4 00024027 _Java_sun_font_FileFont_getGlyphAdvance at 20 > 6 5 0002428C _Java_sun_font_FileFont_getGlyphImage at 20 > 7 6 00024108 _Java_sun_font_FileFont_getGlyphMetrics at 24 > 8 7 00025275 _Java_sun_font_FileFont_getGlyphOutline at 28 > 9 8 000252CC _Java_sun_font_FileFont_getGlyphOutlineBounds at 20 > 10 9 00025321 _Java_sun_font_FileFont_getGlyphVectorOutline at 32 > 11 A 00022EE1 _Java_sun_font_FileFont_getNullScaler at 8 > 12 B 00023D91 _Java_sun_font_FileFont_setNullScaler at 16 > 13 C 000233A7 _Java_sun_font_TrueTypeFont_createScaler at 24 > 14 D 0002463E _Java_sun_font_TrueTypeFont_getGlyphPoint at 24 > 15 E 00022EEB _Java_sun_font_Type1Font_createScaler at 12 > 16 F 00023F13 _Java_sun_font_Type1Font_getGlyphCode at 20 > 17 10 00023EF8 _Java_sun_font_Type1Font_getMissingGlyphCode at 16 > 18 11 00023EDB _Java_sun_font_Type1Font_getNumGlyphs at 16 > 19 12 00023E20 getLayoutTables > 20 13 00023DBD getUnitsPerEmForLayout > 21 14 00023055 isNullScalerContext > 22 15 00022C03 setSunFontIDs > > Summary > > 1000 .data > 7000 .rdata > 2000 .reloc > 1000 .rsrc > 25000 .text > > As you can see, those missing four functions *are* there, in T2K.dll, but > don't have the leading underscore, which somehow the compiler thinks is > there. My guess is that there's a calling convention mixup here somehow, or > else the T2K.lib is somehow written to insert the leading underscores there. > (Which then implies it's not just a straightforward import library, I > think.) Is it possible that there's a macro somewhere in the native code > that's inserting an underscore when it shouldn't? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Monday, July 30, 2007 7:02 AM >> To: Ted Neward >> Cc: build-dev at openjdk.java.net >> Subject: Re: New bug in build process >> >> Is this t2k.lib file the one you created from t2k.dll? >> >> I've never seen these errors before, but it looks like it's in the >> fastdebug build, which would mean you got past the product build, >> which is significant. >> >> This is just a wild guess, but I wonder if the debug t2k.dll file has more >> external symbols than the product one? I'm not that familiar with >> the external list for this library. >> >> --- >> >> Keep in mind that although we regularly build the fastdebug bits (-g -O), >> and >> some developers build the debug bits (-g), neither are tested very >> extensively. >> With the exception of the Hotspot VM, which gets tested fairly well with >> VM type tests. >> It's the product built bits that get most of the formal JDK testing done >> to them. >> >> Product .obj/.o files should end up in a obj directory (under >> build/*/tmp), >> fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you are >> seeing >> some obj_gO references and some obj_g references. Maybe there is another >> bug in >> the BinaryPlugs.gmk file... :^( >> >> -kto >> >> Ted Neward wrote: >>> After doing a ?nuke? of the build dir, and doing a fresh ?make >>> debug_build DEV=1? (again, on Windows), I get this: >>> >>> >>> >>> Creating library >>> c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo >>> >>> nt/fontmanager/obj_gO/fontmanager.lib and object >>> c:/Prg/OpenJDK/openjdk/control/ >>> >>> build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp >>> >>> sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs >>> reference >>> >>> d in function _Java_sun_font_FontManager_initIDs at 8 >>> >>> sunFont.obj : error LNK2019: unresolved external symbol >>> _isNullScalerContext ref >>> >>> erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 >>> >>> SunLayoutEngine.obj : error LNK2019: unresolved external symbol >>> _getUnitsPerEmFo >>> >>> rLayout referenced in function "public: virtual long __thiscall >>> FontInstanceAdap >>> >>> ter::getUnitsPerEM(void)const " >> (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) >>> FontInstanceAdapter.obj : error LNK2001: unresolved external symbol >>> _getUnitsPer >>> >>> EmForLayout >>> >>> FontInstanceAdapter.obj : error LNK2019: unresolved external symbol >>> _getLayoutTa >>> >>> bles referenced in function "public: __thiscall >>> FontInstanceAdapter::FontInstanc >>> >>> eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float >>> *,long,long)" >>> >>> (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) >>> >>> >> c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager >> /obj_g >>> O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals >>> >>> make[5]: *** >>> [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] >>> >>> Error 96 >>> >>> make[5]: Leaving directory >>> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' >>> >>> make[4]: *** [all] Error 1 >>> >>> make[4]: Leaving directory >> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' >>> make[3]: *** [all] Error 1 >>> >>> make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' >>> >>> make[2]: *** [j2se-build] Error 2 >>> >>> make[2]: Leaving directory >> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' >>> make[1]: *** [generic_debug_build] Error 2 >>> >>> make[1]: Leaving directory >> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' >>> make: *** [fastdebug_build] Error 2 >>> >>> CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make >>> >>> $ >>> >>> >>> >>> Apparently there?s some missing object files in the link step of >>> fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related >>> again, since we?re back in the silly font directory again, and yes, I >>> know, t2k is going away soon, but I?d like to see if it can be worked >>> around in the meantime. Legal issues have this annoying tendency to take >>> MUCH longer than engineers think they should? :-) >>> >>> >>> >>> The build output prior to this link line is pretty verbose, but I can >>> send it if it?ll help debug the problem?. >>> >>> >>> >>> Ted Neward >>> >>> Java, .NET, XML Services >>> >>> Consulting, Teaching, Speaking, Writing >>> >>> http://www.tedneward.com >>> >>> >>> >>> >>> >>> >>> No virus found in this outgoing message. >>> Checked by AVG Free Edition. >>> Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: >>> 7/28/2007 3:50 PM >>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007 >> 3:50 PM >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 > 5:26 PM > > From ted at tedneward.com Tue Jul 31 22:38:08 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 31 Jul 2007 15:38:08 -0700 Subject: New bug in build process In-Reply-To: <46AFB577.2060302@sun.com> Message-ID: <101501c7d3c3$7de52080$802ca8c0@XPWork> Weird. *shrug* Oh, well. If b17 is coming by the end of the week, I guess I can wait. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > Sent: Tuesday, July 31, 2007 3:20 PM > To: Ted Neward > Cc: Kelly.Ohair at Sun.COM; build-dev at openjdk.java.net > Subject: Re: New bug in build process > > Ted, > > the code for those methods is (in b16) in > src/share/native/sun/font/scalerMethods.c so you can see for yourself > there's nothing special about them except that the rest are JNI methods > and they aren't : they are called directly from fontmanager.dll so > if they weren't exported properly we'd know about it .. > > Anyway this will all be moot in a few days when b17 is out. > > -phil. > > Ted Neward wrote: > > I think the problem may be more subtle than this; I did a little > > investigation, and missing functions are present in T2K.DLL, but not > with > > the leading underscores. I took a look at the exports from T2K.DLL, and > > they're as follows: > > > > C:\Prg\OpenJDK\BinaryPlugs>dumpbin /exports jdk1.7.0\jre\bin\t2k.dll > > Microsoft (R) COFF/PE Dumper Version 7.10.3077 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > > > Dump of file jdk1.7.0\jre\bin\t2k.dll > > > > File Type: DLL > > > > Section contains the following exports for t2k.dll > > > > 00000000 characteristics > > 468CC934 time date stamp Thu Jul 05 03:34:28 2007 > > 0.00 version > > 1 ordinal base > > 22 number of functions > > 22 number of names > > > > ordinal hint RVA name > > > > 1 0 0002306C > > _Java_sun_font_FileFontStrike_createScalerContext at 44 > > 2 1 0002302E > > _Java_sun_font_FileFontStrike_getNullScalerContext at 16 > > 3 2 00023F9F _Java_sun_font_FileFont_freeScaler at 16 > > 4 3 00024762 _Java_sun_font_FileFont_getFontMetrics at 16 > > 5 4 00024027 _Java_sun_font_FileFont_getGlyphAdvance at 20 > > 6 5 0002428C _Java_sun_font_FileFont_getGlyphImage at 20 > > 7 6 00024108 _Java_sun_font_FileFont_getGlyphMetrics at 24 > > 8 7 00025275 _Java_sun_font_FileFont_getGlyphOutline at 28 > > 9 8 000252CC > _Java_sun_font_FileFont_getGlyphOutlineBounds at 20 > > 10 9 00025321 > _Java_sun_font_FileFont_getGlyphVectorOutline at 32 > > 11 A 00022EE1 _Java_sun_font_FileFont_getNullScaler at 8 > > 12 B 00023D91 _Java_sun_font_FileFont_setNullScaler at 16 > > 13 C 000233A7 _Java_sun_font_TrueTypeFont_createScaler at 24 > > 14 D 0002463E _Java_sun_font_TrueTypeFont_getGlyphPoint at 24 > > 15 E 00022EEB _Java_sun_font_Type1Font_createScaler at 12 > > 16 F 00023F13 _Java_sun_font_Type1Font_getGlyphCode at 20 > > 17 10 00023EF8 > _Java_sun_font_Type1Font_getMissingGlyphCode at 16 > > 18 11 00023EDB _Java_sun_font_Type1Font_getNumGlyphs at 16 > > 19 12 00023E20 getLayoutTables > > 20 13 00023DBD getUnitsPerEmForLayout > > 21 14 00023055 isNullScalerContext > > 22 15 00022C03 setSunFontIDs > > > > Summary > > > > 1000 .data > > 7000 .rdata > > 2000 .reloc > > 1000 .rsrc > > 25000 .text > > > > As you can see, those missing four functions *are* there, in T2K.dll, > but > > don't have the leading underscore, which somehow the compiler thinks is > > there. My guess is that there's a calling convention mixup here somehow, > or > > else the T2K.lib is somehow written to insert the leading underscores > there. > > (Which then implies it's not just a straightforward import library, I > > think.) Is it possible that there's a macro somewhere in the native code > > that's inserting an underscore when it shouldn't? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >> Sent: Monday, July 30, 2007 7:02 AM > >> To: Ted Neward > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: New bug in build process > >> > >> Is this t2k.lib file the one you created from t2k.dll? > >> > >> I've never seen these errors before, but it looks like it's in the > >> fastdebug build, which would mean you got past the product build, > >> which is significant. > >> > >> This is just a wild guess, but I wonder if the debug t2k.dll file has > more > >> external symbols than the product one? I'm not that familiar with > >> the external list for this library. > >> > >> --- > >> > >> Keep in mind that although we regularly build the fastdebug bits (-g - > O), > >> and > >> some developers build the debug bits (-g), neither are tested very > >> extensively. > >> With the exception of the Hotspot VM, which gets tested fairly well > with > >> VM type tests. > >> It's the product built bits that get most of the formal JDK testing > done > >> to them. > >> > >> Product .obj/.o files should end up in a obj directory (under > >> build/*/tmp), > >> fastdebug ones in obj_gO, and debug ones in obj_g. I'm curious why you > are > >> seeing > >> some obj_gO references and some obj_g references. Maybe there is > another > >> bug in > >> the BinaryPlugs.gmk file... :^( > >> > >> -kto > >> > >> Ted Neward wrote: > >>> After doing a ?nuke? of the build dir, and doing a fresh ?make > >>> debug_build DEV=1? (again, on Windows), I get this: > >>> > >>> > >>> > >>> Creating library > >>> c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.fo > >>> > >>> nt/fontmanager/obj_gO/fontmanager.lib and object > >>> c:/Prg/OpenJDK/openjdk/control/ > >>> > >>> build/WINDOW~2/tmp/sun/sun.font/fontmanager/obj_gO/fontmanager.exp > >>> > >>> sunFont.obj : error LNK2019: unresolved external symbol _setSunFontIDs > >>> reference > >>> > >>> d in function _Java_sun_font_FontManager_initIDs at 8 > >>> > >>> sunFont.obj : error LNK2019: unresolved external symbol > >>> _isNullScalerContext ref > >>> > >>> erenced in function _Java_sun_font_StrikeCache_freeIntMemory at 20 > >>> > >>> SunLayoutEngine.obj : error LNK2019: unresolved external symbol > >>> _getUnitsPerEmFo > >>> > >>> rLayout referenced in function "public: virtual long __thiscall > >>> FontInstanceAdap > >>> > >>> ter::getUnitsPerEM(void)const " > >> (?getUnitsPerEM at FontInstanceAdapter@@UBEJXZ) > >>> FontInstanceAdapter.obj : error LNK2001: unresolved external symbol > >>> _getUnitsPer > >>> > >>> EmForLayout > >>> > >>> FontInstanceAdapter.obj : error LNK2019: unresolved external symbol > >>> _getLayoutTa > >>> > >>> bles referenced in function "public: __thiscall > >>> FontInstanceAdapter::FontInstanc > >>> > >>> eAdapter(struct JNIEnv_ *,class _jobject *,class _jobject *,float > >>> *,long,long)" > >>> > >>> (??0FontInstanceAdapter@@QAE at PAUJNIEnv_@@PAV_jobject@@1PAMJJ at Z) > >>> > >>> > >> > c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/tmp/sun/sun.font/fontmanager > >> /obj_g > >>> O/fontmanager.dll : fatal error LNK1120: 4 unresolved externals > >>> > >>> make[5]: *** > >>> [c:/Prg/OpenJDK/openjdk/control/build/WINDOW~2/bin/fontmanager.dll] > >>> > >>> Error 96 > >>> > >>> make[5]: Leaving directory > >>> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font' > >>> > >>> make[4]: *** [all] Error 1 > >>> > >>> make[4]: Leaving directory > >> `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun' > >>> make[3]: *** [all] Error 1 > >>> > >>> make[3]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make' > >>> > >>> make[2]: *** [j2se-build] Error 2 > >>> > >>> make[2]: Leaving directory > >> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > >>> make[1]: *** [generic_debug_build] Error 2 > >>> > >>> make[1]: Leaving directory > >> `/cygdrive/c/Prg/OpenJDK/openjdk/control/make' > >>> make: *** [fastdebug_build] Error 2 > >>> > >>> CYGWIN:Ted at XPJAVA:/cygdrive/c/Prg/OpenJDK/openjdk/control/make > >>> > >>> $ > >>> > >>> > >>> > >>> Apparently there?s some missing object files in the link step of > >>> fontmanager.lib; any ideas? Intuition tells me this is t2k.lib-related > >>> again, since we?re back in the silly font directory again, and yes, I > >>> know, t2k is going away soon, but I?d like to see if it can be worked > >>> around in the meantime. Legal issues have this annoying tendency to > take > >>> MUCH longer than engineers think they should? :-) > >>> > >>> > >>> > >>> The build output prior to this link line is pretty verbose, but I can > >>> send it if it?ll help debug the problem?. > >>> > >>> > >>> > >>> Ted Neward > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > >>> 7/28/2007 3:50 PM > >>> > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: > 7/28/2007 > >> 3:50 PM > >> > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: > 7/31/2007 > > 5:26 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 > 5:26 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 5:26 PM