This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin 64bit triplet
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 21 Feb 2013 13:11:33 +0100
- Subject: Re: Cygwin 64bit triplet
- References: <20130220211406.253d7332@YAAKOV04>
- Reply-to: cygwin-developers at cygwin dot com
On Feb 20 21:14, Yaakov wrote:
> The bootstrap toolchain provided so far has used the x86_64-pc-cygwin
> triplet. The problem is, now that we've managed to get far enough
> (before I threw a wrench into everything today :-) to begin using
> cygport on x86_64, I found out the hard way that gnuconfig is a bit
> confused wrt this platform.
> Run config.guess on x86_64-cygwin and it returns
> 'x86_64-unknown-cygwin', which is what autoconf-generated configures
> rely upon for build/host/target unless specified as arguments. But
> config.sub x86_64-cygwin returns 'x86_64-pc-cygwin' with this comment
> in the corresponding code:
> > # We use `pc' rather than `unknown'
> > # because (1) that's what they normally are, and
> > # (2) the word "unknown" tends to confuse beginning users.
> This part isn't Cygwin specific; x86_64/amd64 with any $os, including
> Linux, will return x86_64-pc-$os[-$libc]. (Of course, if a full triplet
> is provided, it will accept whatever $company you throw at it.)
> OTOH, MinGW is always config.guess'ed as $machine-pc-mingw*, where
> other systems only get that treatment on ix86.
> Now, for native compiling, this really doesn't matter so much. For
> example, RH/Fedora gcc is e.g. x86_64-redhat-linux but %_host is
> x86_64-unknown-linux-gnu. However, there are currently at least three
> * winsup/cygwin/Makefile.in and winsup/lsaauth/Makefile.in use
> x86_64-pc-cygwin to determine 64bit-ness; these checks could be
> changed to use a substring or @target_cpu@ etc.
I changed that in CVS.
> * winsup/cygwin/cygwin.sc.in assumes x86_64-pc-cygwin; this could be
> worked around with a sed call.
Huh? cygwin.sc.in only uses "#ifdef __x86_64__", and the Makefile
just calls $(CC) to create cygwin.sc from it.
> * cygport master currently assumes host=x86_64-pc-cygwin, so when the
> included config.guess returns x86_64-unknown-cygwin, it assumes
> cross-compiling mode.
That could be a simple tweak in cygport.
> To keep this simple, we probably want to stop this mismatch before it
> gets too far. AFAICS the options are:
> 1) Change config.guess to 'x86_64-pc-cygwin' and deal with fixing this
> upstream, get it pulled into the toplevel copy, and let it filter down
> from there;
> 2) We switch to 'x86_64-unknown-cygwin' now and rebuild our toolchains
> (both native and cross) to match, which we now have to do anyway.
I wouldn't want to do that. The "unknown" is really weird. I'm a bit
puzzled. Why and where is the second part of the triplet important?
Why isn't it important under Linux?
> (BTW, the funny part is that, according to git log, x86_64-cygwin was
> added to config.guess 8 years ago this month, and ix86-cygwin and
> powerpc-cygwin (!) were added 17 years ago this month.)
Heh. Some things take a bit longer...
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com