This is the mail archive of the cygwin-developers 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: Cygwin 64bit triplet

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
> issues:
> * winsup/cygwin/ and winsup/lsaauth/ 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/ assumes x86_64-pc-cygwin; this could be
>   worked around with a sed call.

Huh? only uses "#ifdef __x86_64__", and the Makefile
just calls $(CC) to create 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
Red Hat

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