This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Cygwin 64bit triplet
- From: Yaakov (Cygwin/X) <yselkowitz at users dot sourceforge dot net>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 20 Feb 2013 21:14:06 -0600
- Subject: Cygwin 64bit triplet
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
issues:
* 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.
* winsup/cygwin/cygwin.sc.in assumes x86_64-pc-cygwin; this could be
worked around with a sed call.
* 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.
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.
(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.)
Yaakov