Hi Damjan, I have VisualStudio Professional installed and I still have troubles building OpenJDK along the explanations given in the README and other blogs.
So, my question with MinGW was not about a zero costs tool but about an alternative to try out in place of VisualStudio and its related problems. Hence, what I did in the last few days was to retry the standard route with VisualStudio but with a lot more patience and a lot more time planned to do the build. I made some steps forward (e.g., luckily I didn't have much troubles with FreeType) but I'm now stuck with real compilation errors that cannot be overcome by simply changing the configuration, I guess. Anyway, thank you for having put your experience to a blog. Raffaello On 2010-05-05 14:37, Damjan Jovanovic wrote: > Hi Raffaello > > Hope this isn't too late, but if you're merely looking for a free as > opposed to an open source compiler to build OpenJDK, then Visual > Studio Express edition can be used too: > > http://mail.openjdk.java.net/pipermail/build-dev/2009-December/002641.html > > I've documented some other Windows build gotchas in that email too. > > Good luck > Damjan > > On Fri, Apr 23, 2010 at 5:42 PM, Raffaello Giulietti > <[email protected]> wrote: >> Let me put things in perspective. >> >> I'm not interested in building OpenJDK7 per se. I would use the binary >> snapshots, were it not for the fact that, for my purposes, I need the >> latest extensions provided by the MLVM project. Unfortunately, there is >> no binary snapshot for that, so I need to download the Mercurial >> repository, apply the MLVM specific patches and build it. >> >> Now, I invested two frustrating days in trying to build the "pure" >> OpenJDK7, i.e., without the MLVM extensions. I did it according to the >> details described in the quite complete "OpenJDK Build README" page. So >> I used the expected licensed VisualStudio compiler. The problems I >> encountered can be generally grouped in the "path not found" category, >> be it because of spaces in the path, because of \ versus /, etc. As a >> consequence, I didn't even try a build with the MLVM extensions. >> >> To be clear, I'm not complaining about the README or the like. I'm only >> reporting my experience with such a complex system and its build. >> >> So, the real reason behind my request for a MinGW based build is that it >> would be a second chance to try a build of the MLVM. But since nobody >> seems to have first-hand experience with OpenJDK7/MinGW, I'll gather my >> energies and my patience and retry with VisualStudio. >> >> RG >> >> >> >> On 2010-04-21 18:40, Kelly O'Hair wrote: >>> >>> On Apr 21, 2010, at 5:58 AM, Raffaello Giulietti wrote: >>> >>>> Hello, >>>> >>>> I'm wondering if anybody has already tried to build OpenJDK7 on Windows >>>> using the MinGW suite. >>> >>> If they have, I never heard from them. >>> >>>> >>>> * Is there anything known to be a hard to circumvent show stopper? >>> >>> To me the basic problem is that with "Windows" it is hard to separate >>> the code >>> dependencies on the OS, some Windows SDK, something specific to Visual >>> Studio, >>> etc. I'm not saying it would be impossible, but it is not a simple >>> change and >>> parts of the jdk might be very difficult to disconnect from Visual Studio >>> dependencies. The code has assumed Visual Studio for a long long time. >>> >>> If someone did it, and we were able to build either way, and the changes >>> weren't >>> too outrageous, I'm sure we consider accepting that contribution. >>> But I just don't think it will be that simple. >>> >>>> * Is it known why Visual C++ is still the reference build system on >>>> Windows? >>> >>> It was probably chosen as the defacto standard on Windows a long time >>> ago and >>> there was never any value in changing that. >>> The performance was probably a key issue, and whether or not you could >>> convert >>> to a different compiler set, before the official builds would ever >>> change you >>> would need some very detailed performance measurements to verify no loss of >>> performance. That's not an easy job, or simple either. >>> >>> --- >>> >>> Any change to the compilers used to create the binary JDKs we distribute >>> is always >>> a change made very carefully. It might provide significant benefits, but >>> the >>> hidden dangers are often difficult to find and diagnose. >>> I know this binary distribution model is of less interest to some who >>> just want >>> to build the openjdk source for a particular platform, but it certainly >>> is a >>> critical issue for us. Compiler changes are carefully tracked. >>> >>> -kto >>> >>>> >>>> Thanks >>>> Raffaello >>> >> >>
