Building with MinGW?

[Raffaello Giulietti]

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
> <raffaello.giulietti at gmail.com> 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
>>>
>>
>>