Re: 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 <fwei...@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