Cross-building Windows binaries using the mingw toolchain

[Ivan Krylov]

What would this give in practical terms? Suppose you are working on a 
cross-platform bug or feature. You want to make sure that the fix works 
on Windows as well. I would think that testing the fix with 
cross-compiled build would be insufficient for the reasons that Volker 
lists. If the produced bits aren't the same (and they won't be the same) 
we can not trust the results of such testing. And the test matrix for 
openjdk is already rather complex and making it even more complex with 
cross-compilation options will not help. And one still needs at least a 
virtualized copy of Windows to run tests anyways.
I am not sure what is the status of Visual Studio Express support by the 
build chain but I'd rather see  that in place as an alternative to the 
use of Visual Studio Professional.This way the produces jdk binaries 
will be much closer to the stock ones.

Thanks,
Ivan

On 30/04/14 19:00 , Volker Simonis wrote:
> On Wed, Apr 30, 2014 at 6:31 PM, Florian Weimer <fweimer at redhat.com> wrote:
>> On 04/30/2014 06:16 PM, Volker Simonis wrote:
>>
>>> The first one is to make the OpenJDK compile on Windows with the MinGW
>>> toolchain (instead of Cygwin). This currently doesn't work out of the
>>> box but is relatively easy to achieve (see for example "8022177:
>>> Windows/MSYS builds broken"
>>> https://bugs.openjdk.java.net/browse/JDK-8022177). Magnus and I are
>>> working on this (and actually I have an internal build which works
>>> with MinGW). Hopefully we can fix this in the OpenJDK soon.
>>
>> Thanks for your input.  If you say "MingW toolchain", you mean the scripting
>> environment, but not the compiler and linker, right?
>>
>>
>>> The second one is to cross compile the whole OpenJDK on Linux using
>>> gcc and MingGW. If I understood you right that's what you actually
>>> wanted.
>>
>> Yes, that's what I'm interested in.
>>
>>
>>> I personally think that would be nice to have but at the same
>>>
>>> time I also think it would be quite hard to get there and probably not
>>> worth doing it because even if you'd succeed nobody will probably
>>> maintain it and it would break quite soon (see for example the
>>> GCC/Solaris build or the Clang/Linux build).
>>
>> It's clear to me that this is worthwhile only if I set up a builder which
>> detects bit rot quickly.
>>
>>
>>> If you want to try it nevertheless, some of the problems you will face
>>> will be at least the following ones:
>>> - convert the HotSpot nmake makefiles to GNU syntax (notice that this
>>> project is currently underway under the umbrella of the new build
>>> system anyway, so you'd probably want to wait to avoid doing double
>>> work)
>>
>> Ah, interesting.
>>
>>
>>> - convert Visual Studio intrinsics, inline assembler and compiler
>>> idiosyncrasies to GCC syntax
>>
>> Ahh, I wonder how much I will encounter there.  That would be prerequisite
>> for a pure-mingw build on Windows as well, right?
>>
>>
>>> - you'll probably also need to cross compile dependencies like
>>> libfreetype with GCC/MinGW
>>
>> Fedora already covers those, although the paths are somewhat unexpected.
>>
>>
>>> - I'm actually not an expert, but the OpenJDK is linked against some
>>> native Window libraries like DirectX and runtime libraries from the
>>> Microsoft SDKs. I'm not an expert here and I don't know how that would
>>> work for a cross-compile.
>>
>> We supposedly have the headers and import libraries in Fedora.
>>
>>
>>> I personally think we should rather focus on further improving the
>>> current Windows build. It's already a huge improvement compared to the
>>> old JDK7 Windows build. From what I see, the main remaining problems
>>> are to somehow make it possible to get a stable, defined and free
>>> version of the Microsoft development tools which are "known to work".
>>
>> Yes, I tried to set up a Windows development environment, but quickly got
>> confused.
>>
>> My background here is that I want to contribute some new features and I
>> expect that feature parity for Windows will increase the likelihood of
>> acceptance.
>>
> But why can't you install Cygwin and the free Microsoft Express/SDK
> compilers and do a native build. From my experience that's a matter of
> some hours (and you can find quite some documentation/tutorials/help
> on the web and on the various mailing lists). Doing that you could be
> sure that you really test what others (i.e. especially Oracle) will
> get. Cross-compiling your new feature with a MinGW toolchain doesn't
> mean that others will be able to compile and run that code with a
> native Windows build tool chain (it would be actually quite easy to
> introduce changes which work for the MinGW cross-build but break for
> the native build) So I don't see how that would increase the
> confidence in your change.
>
>  From my experience, native OpenJDK changes (and often even trivial
> ones) should be build and tested at least on Linux and Windows (this
> already exercises your changes on two different OSs with two different
> compilers). Bigger shared changes should also be tested on MacOS X
> (which is quite "cheap" and gives you a third OS and compiler) and
> Solaris (which is hard nowadays).
>
>> I need to think about it, but for my purposes, a pure mingw environment
>> running on Windows would work as well.  It would be less specialized, so
>> perhaps there is more interest in that.
>>
>>
>> --
>> Florian Weimer / Red Hat Product Security Team