Discuss: Base packages for Win32 / Win64 / OS X cross-compilation

Richard W.M. Jones rjones at redhat.com
Wed Feb 11 20:47:04 UTC 2009

This diagram shows what packages we could end up with if we go for
full Win32, Win64 and OS X (ppc/i386) cross-compilation:

  mingw32-               mingw64-               darwinx-
  filesystem             filesystem             filesystem

  binutils               binutils               odcctools
    (from mingw)           (from upstream)        (from Apple)

  gcc                    gcc                    gcc
    (from upstream)        (from upstream)        (from Apple)

  w32api                 headers                headers
    (from mingw)           (from mw64)            (from Apple)

  runtime                runtime                -
    (from mingw)           (from mw64)

where "mingw" = mingw.org, "mw64" = mingw-w64.

Of these, what might be combined?

(1) mingw32-filesystem / mingw64-filesystem / darwinx-filesystem.

These could be combined, but there seems to be very little reason to
do so.  There wouldn't be very much shared in common by these three

(2) mingw32-gcc / mingw64-gcc

The Source for both of these would be the same, and there is some
value in building from the same source and not allowing the compiler
versions to get out of step.

>From here, I cannot see any other packages out of the above which are
good candidates to be combined.  All the other packages come from
different sources.
			-	-	-
For libraries the situation is a bit different.  Taking zlib as the
canonical example:

  mingw32-               mingw64-               darwinx-
  zlib                   zlib                   zlib

Either zlib compiles on all 3 platforms, in which case simply from
a management perspective it makes sense to have a single source
RPM generating all 3 packages.  Or zlib doesn't compile / is missing
from some platform, eg:

  mingw32-               mingw64-               darwinx-
  zlib                   zlib                     x

in which case it still seems to make sense to build from a single
source RPM.  The only time I could see it making sense to build from
different SRPMS would be if either (a) different people needed to
manage the ports, or (b) for some reason we had to use a different
upstream on one of the platforms.

So ... I think this leads to the conclusion that we need the extra
base packages shown in the diagram at top.  But for libraries, we
should stay with single source RPM and try to build on all three

For development tools it's likely we'll need to deal with things on a
case-by-case basis -- eg. nsis is only applicable on mingw32, and you
would need something completely different to make darwinx installers.

Please follow up if you disagree (or agree ...)


Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)

More information about the mingw mailing list