This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Cygwin 64bit triplet
On Feb 22 01:20, Yaakov wrote:
> On Thu, 21 Feb 2013 13:11:33 +0100, Corinna Vinschen wrote:
> > On Feb 20 21:14, Yaakov wrote:
> > > * 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.
>
> $ grep -r x86_64-pc-cygwin .
> ./cygwin/cygwin.sc.in:SEARCH_DIR("/usr/x86_64-pc-cygwin/lib/w32api"); SEARCH_DIR("=/usr/lib/w32api");
>
> As long as we keep using --target=x86_64-pc-cygwin for the non-sysroot
> cross-compiler, this is fine.
>
> > > * 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.
>
> Correct.
>
> > > 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?
>
> It's not so much *what* it is, but its the consistency that's important.
> As it stands right now, if I were to manually build a package without
> any --build/--host/--target, it would assume all are
> x86_64-unknown-cygwin, use just "gcc" etc. and it would be fine. But if
> instead I configured with --host=x86_64-pc-cygwin and no --build,
> configure would think I'm trying to cross-compile. The same goes for
> building binutils/gcc with only --target=x86_64-pc-cygwin, it would
> think I'm trying to build a cross-compiler.
>
> While I can work around this in cygport, if we want to use 'pc' then we
> should get config.guess fixed both upstream and in the "toplevel"
> copy, and make sure our automake and libtool packages ship a
> current/patched copy as well.
Sorry, but I still don't grok it. If I run config.guess and config.sub
on 64 bit Linux, I get:
$ ./config.guess
x86_64-unknown-linux-gnu
$ ./config.sub x86_64-linux
x86_64-pc-linux-gnu
On Cygwin:
$ ./config.guess
x86_64-unknown-cygwin
$ ./config.sub x86_64-linux
x86_64-pc-cygwin
This looks rather consistent to me. Why and how is Linux here different
from Cygwin? If Linux can live with this, why can't we?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat