MinGW-w64

Mojca Miklavec mojca at macports.org
Wed Jan 14 02:36:43 PST 2015


Hi,

Seeing the instructions about compiling clang-3.5 on Leopard in
several stages reminded me on another project that is lagging behind –
MinGW-w64
    http://trac.macports.org/ticket/40174
    http://trac.macports.org/browser/users/mojca/ports/cross

The ports for mingw that are currently in MacPorts are horribly
outdated and don't support creating 64-bit windows binaries.

I don't have much time at the moment (I need to catch some deadlines
first, and then refresh my memory of what I did), but I have a working
cross-compiler for windows (slightly outdated though – from 7 months
ago) and the corresponding Portfiles.

The reason why I didn't commit the changes was because I wasn't sure
how to (properly and efficiently) implement the bootstrapping phase.

The general procedure is roughly:

a) install binutils (easy)
b) install headers (easy)
c) build gcc ("make [install] all-gcc" from GCC sources)
d) build crt (requires gcc)
e) build libgcc from gcc sources ("make [install] all-target-libgcc"
from GCC sources)
f) build pthreads (requires libgcc and crt)
g) build gcc again ("make [install]" from GCC sources)

In an efficient implementation the steps (c), (e), (g) are compiled
from the same source. I don't know how to do that within the MacPorts
framework. If (e) or (g) are already installed, there is no need to
repeat the build step (c); there is also no need to do (e) if (g) is
already installed.

If (c), (e) and (g) were separate ports, they would either need to
conflict with each other, or someone should make sure that files
installed by (c) get removed from (e) and files installed by (c) and
(e) get removed from (g). It would be easier (and probably better) if
(g) would automatically deactivate (c) or (e) before its own
activation.

If users would fetch binaries from the buildbot, they could skip
fetching (c) and (e) and go straight to (g). But for an out-of-source
build, they would have to start compiling (c). Also, compiling either
of these steps takes soooooooo long. It would help a lot if (e) and
(g) could continue compiling from where (c) (and (e)) left.

I would be grateful for any hints about how to approach the challenge.
Ideally the building tools would support the bootstraping without the
extra complications (one could use gcc and headers from a temporary
location when building crt and pthreads for example), but sadly that's
not the case yet.

I would certainly need more help to get these ports to work properly,
but it would be really nice to have the ability to cross-compile some
simple apps for Windows on Mac.

Mojca


More information about the macports-dev mailing list