This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: i686-pc-mingw32 cross compiler
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