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


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