i686-pc-mingw32 cross compiler

[Yaakov (Cygwin/X)]

On Thu, 2010-10-28 at 18:21 -0400, Charles Wilson wrote:
> I've been using one of my own for a couple of months now (probably very
> similar to yours).  I also worked thru the issues related to the "new"
> required locations of the "mingw-runtime/w32api for the mingw cross
> compiler" vs the "mingw-runtime/w32api for cygwin's compiler".  (e.g. my
> "gcc-3 -mno-cygwin" compiler can use the mingw-cross-compiler's
> mingw-runtime and w32api packages, with a little help). I documented
> this here:
> http://cygwin.com/ml/cygwin-apps/2010-07/msg00179.html

Do we *really* still need gcc-3 -mno-cygwin?  Both winsup and setup.exe
build with a sysrooted gcc-4.5 now.

Even better yet, why do we still need gcc3 at all?

> However, I wasn't planning on releasing the new cross toolchain myself,
> since IIRC Dave had sorta taken ownership of it (he owns gcc-3, with its
> --mno-cygwin mode, after all).  Plus, I'm sorta clueless when it comes
> to the innards of modern gcc; the last time I really dug into the guts
> of gcc and binutils was around 2000.

Of course it's Dave's call, but gcc-mingw-* is his only because it's
tied into gcc3; that correlation ceases to exist with a true
cross-compiling toolchain.  I know if I were in his shoes, I'd give it
over in a heartbeat. :-)

As for understanding the innards of gcc/binutils, it really shouldn't be
necessary for cross-gcc package maintainers; we should be able to rely
on each platform's native user base to maintain their platform.

> OTOH, I'm probably the best liaison between "us" and mingw.org (well, me
> or Chris Sutcliffe) since I'm active "over there".

My thoughts exactly. :-)

> I guess it boils down to this: I'm willing to package it and work thru
> the initial teething pains, but I don't think I'm really qualified to
> "support" the mingw cross compiler...unless...
> 
> We *could* take the position that: "We just package mingw.org's compiler
> built as a cygwin-hosted cross toolchain.  We'll fix obvious packaging
> bugs, and ensure that setup.exe can be built (as a reasonable "smoke
> test"), but if there are any OTHER problems with the toolchain...go talk
> to mingw.org"

Which would be no different from any other package that we ship.

> However...to really "get away with that" attitude, we have to use the
> mingw.org 'cross-build-script', because they only support toolchains
> built using it.
> https://sourceforge.net/projects/mingw/files_beta/Cross-Hosted%20MinGW%20Build%20Tool/x86-mingw32-build-1.0.1-rc1/

Really?  I doubt any Linux distro uses those scripts to build their
mingw-* packages.  What do they have to say about that?

> 'Course, we might be able to work with them, and get them to extend that
> attitude to "or the cygwin packaged version". That'll require some
> negotiations, and we'll have to be very careful to ensure that "our"
> mingw-cross toolchain is built exactly as their cross-tool-script would.
> (Which is odd, because THEIR cross-tool-script configures the toolchain
> *differently* that THEIR native one is configured -- and I'm not talking
> about the obvious --build/--host issues).

Like --enable-sjlj-exceptions??  I was sure that they used dw2.

Certainly the (important) configure options need to match, otherwise
output will be incompatible, but using their scripts or ours should be
negotiable.

I would encourage you to proceed as you say, pending coordination with
Dave and Chris.  I think this has waited long enough.

(BTW, once we've switched, I'm considering packaging a cross-GTK+.)


Yaakov