This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i686-pc-mingw32 cross compiler


On 10/29/2010 1:26 AM, Yaakov (Cygwin/X) wrote:
> On Thu, 2010-10-28 at 18:21 -0400, Charles Wilson wrote:
>> (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
> 
> 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?

Well, we don't *need* it.  But...I think it would be nice to have a
transition period, where both mingw-gcc and gcc-3-mno-cygwin are
available: rather than requiring current users of gcc-3-mno-cygwin to
switch on a dime, as soon as we publish mingw-gcc and *break*
gcc-3-mno-cygwin.

I know, I know -- my proposal goes against our WJM philosophy, but...

In six months or so, we move 'em to _obsolete status.

> 
> 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. :-)

Right. I gave him a ping this morning.

> 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.

You're right, we SHOULD. But...that has not, historically, been the case
for the mingw.org guys. (*)  "Use our cross build script, or go away".

I understand the motivation: MOST cross-tool users and cross-toolchain
builders are fairly knowledgeable -- but as always, if win32 is
involved...the noobs come out in droves.  Hence, an automated script to
"do it right"; it's a very short step from there to "we only support you
if you used the script".

IMO, this "policy" of thiers ("ours" really, since I'm now on the
mingw.org admin team) is going to have to change: at minimum, they ought
not simply ignore cross toolchains that are SHIPPED by distributions,
ASSUMING they are using i686-pc-mingw32 and not i686-w64-mingw32.
Certainly the division of labor is a little fuzzy between, say, fedora's
mingw-* team, and mingw.org -- but it should NOT be, as presently, 100%
fedora and 0% mingw.org.  I think similar arguments would apply vis.
cygwin's mingw-gcc.

(*) Nightstrike, no comments, please.

>> 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.

Not really. Take inetuils: nobody on the inetutils mailing list was at
all interested in "fixing" inetutils FOR cygwin. They MIGHT accept
patches *I* (or Corinna) developed...but that's the best we could hope
for.  This meant that *I* -- as the cygwin inetutils maintainer -- had
to debug the innards of inetd and telnetd myself, etc etc.  Similar
things are true wrt Eric's cygwin-coreutils, Corinna's cygwin-openssh,
etc etc.

If that sort of effort becomes necessary wrt cygwin's mingw-gcc or
cygwin's mingw-binutils...I'm not the guy.

>> 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?

They don't support it.  I think this is both a tactical and strategic
mistake, and I believe it should change.  We (meaning "mingw.org") ought
to assume that distro packagers will get it "mostly" correct. Even if
they include, as fedora does, a bunch of patches that mingw.org's own
dists do not.

OTOH, mingw.org has switched officially to dw2, but (for instance)
mandriva's mingw toochain is i586-pc-mingw32 (that is, it isn't a 32bit
spin of mingw64) but uses sjlj -- mainly because, in UPSTREAM gcc,
that's still the default IIRC.  Sadly, this means that libs
cross-compiled using the mandriva mingw-* packageset are not
interoperable with mingw.org's own offerings.

Should mingw.org support that?

fedora, on the other hand, provides i686-pc-mingw32-gcc that is dw2.

>> '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.

You're right.  That's the biggest exception: the cross compiler built
using the script has, by default, A DIFFERENT FRACKING ABI than the
native mingw.org gcc.  Dumb dumb grumble mutter stupid mutter....

In fairness, the reason for this is that the script is still configured,
by default, to build gcc-3.4.5 -- which DID use sjlj.  But if someone
were to customize the script to build gcc-4.x, but did NOT also
customize it to use dw2...

And the necessity of keeping these two "configuration choices" in proper
sync doesn't appear to be documented.

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

You're right, and I agree. Especially as the script contains a big
section for *customizing* those configure options.  I mean, really: I'd
rather support (cross) compilers that are built using ANY buildtool, but
with the SAME configure options -- than support (cross) compilers built
using a specific buildtool but with any customized configure options
imaginable, that might change the ABI.

The current mingw.org "policy" is...not well thought out. IMNSHO.

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

Agreed. I'm waiting for Dave to comment on this thread.  If Dave agrees,
I'll go ahead and package
  mingw-gcc
  mingw-binutils
  mingw-w32api
  mingw-runtime (*)
  mingw-pthreads

  mingw-zlib
  mingw-xz+liblzma
  mingw-bzip2
  mingw-libgcrypt
  mingw-libgpg-error

and re-package

  gcc-mingw-*

This ^^^ would basically consist of a new package(s) that forces the
*previously* installed version's preremove script to run, and then, as
part of its (new) postinstall procedure, cleans up the rest of the junk
left behind by that preremove.

I'll also re-package or update the requires: of the gcc-3 packages, as
necessary.  If Chris wants to then take over mingw-w32api, that's fine
with me.


(*) This one is odd.  It actually ought to *replace* the current
mingw-runtime package...but as Chris owns that one...well, we'll have to
coordinate.  I think, ultimately -- if Chris agrees -- he should
eventually own the mingw-runtime, mingw-w32api, and w32api packages --
regardless of whether I happen to provide the initial (new) cross-built
version of the two mingw-* ones.

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

Errr...why?  I mean, for cygwin-ports (cygwin-mingw-ports?), fine.  But
in the cygwin distro?  It's not "cygwin".  It's not even necessary for
building setup.exe.  We've rejected offers to maintain mingw-jpeg,
mingw-tiff, etc, in the past...

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]