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


Yaakov


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