Cygwin 64bit triplet

[Yaakov (Cygwin/X)]

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

# 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

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)
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

# 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
* winsup/cygwin/Makefile.in and winsup/lsaauth/Makefile.in use
x86_64-pc-cygwin to determine 64bit-ness; these checks could be

I changed that in CVS.

Post by Yaakov (Cygwin/X)
* 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.

Post by Yaakov (Cygwin/X)
* 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.

Post by Yaakov (Cygwin/X)
To keep this simple, we probably want to stop this mismatch before it
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?

Post by Yaakov (Cygwin/X)
(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

[Earnie Boyd]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
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?

<quote>
A three part configuration name is: cpu-manufacturer-operating system
A four part configuration name is: cpu-manufacturer-kernel-operating system
The manufacturer can sometimes be omited.
</quote>

So it could be x86_64-redhat-cygwin but it doesn't really matter from
autoconf's POV.

[Corinna Vinschen]

Post by Earnie Boyd

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
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?

<quote>
A three part configuration name is: cpu-manufacturer-operating system
A four part configuration name is: cpu-manufacturer-kernel-operating system
The manufacturer can sometimes be omited.
</quote>
So it could be x86_64-redhat-cygwin but it doesn't really matter from
autoconf's POV.

But in some scenarios it does matter, otherwise Yaakov wouldn't have
mentioned it.


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
* 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.

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
* 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.

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
To keep this simple, we probably want to stop this mismatch before it
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

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
* 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.

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
* 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.

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
To keep this simple, we probably want to stop this mismatch before it
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

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
Sorry, but I still don't grok it. If I run config.guess and config.sub
$ ./config.guess
x86_64-unknown-linux-gnu
$ ./config.sub x86_64-linux
x86_64-pc-linux-gnu
$ ./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?

It's not different from Linux: the very fact that config.guess and
config.sub provide two different responses for what should be the same
system is inconsistent. But let's leave config.sub out of this for now
though.

Post by Corinna Vinschen
If Linux can live with this, why can't we?

We can -- if we use x86_64-unknown-cygwin as the "canonical" triplet,
just like Linux uses x86_64-unknown-linux-gnu, since config.guess is the
more important of the two here. (config.sub only matters if you use an
incomplete triplet, as is customary with some embedded platforms.)
However, right now we're using x86_64-pc-cygwin, and *that* is where
the problem exists, so we need to choose:

* x86_64-unknown-cygwin: easy to adapt (just adjust bootstrap.sh and
cygwin.sc.in, then rebuild), naming scheme matches Linux, but doesn't
sound/look as nice.

* x86_64-pc-cygwin: sounds/looks nicer, naming scheme matches MinGW, but
getting everything to conform to that OOTB is more work.


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
Sorry, but I still don't grok it. If I run config.guess and config.sub
$ ./config.guess
x86_64-unknown-linux-gnu
$ ./config.sub x86_64-linux
x86_64-pc-linux-gnu
$ ./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?

It's not different from Linux: the very fact that config.guess and
config.sub provide two different responses for what should be the same
system is inconsistent. But let's leave config.sub out of this for now
though.

Post by Corinna Vinschen
If Linux can live with this, why can't we?

We can -- if we use x86_64-unknown-cygwin as the "canonical" triplet,
just like Linux uses x86_64-unknown-linux-gnu, since config.guess is the
more important of the two here. (config.sub only matters if you use an
incomplete triplet, as is customary with some embedded platforms.)
However, right now we're using x86_64-pc-cygwin, and *that* is where
* x86_64-unknown-cygwin: easy to adapt (just adjust bootstrap.sh and
cygwin.sc.in, then rebuild), naming scheme matches Linux, but doesn't
sound/look as nice.
* x86_64-pc-cygwin: sounds/looks nicer, naming scheme matches MinGW, but
getting everything to conform to that OOTB is more work.

Last set of questions (and yes, I'm really not an expert): Why can
Fedora/RHEL use x86_64-redhat-linux as canonical triplet, and why has
Fedora/RHEL apparently no problems with that?


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
Last set of questions (and yes, I'm really not an expert): Why can
Fedora/RHEL use x86_64-redhat-linux as canonical triplet, and why has
Fedora/RHEL apparently no problems with that?

It is only so far as binutils/gcc/gdb are concerned, otherwise it's
x86_64-unknown-linux-gnu. We should be able to handle things like that
as well: x86_64-pc-cygwin for the toolchains (native and cross) but
leave config.guess alone (x86_64-unknown-cygwin), which by itself
isn't all that visible. I just need to adjust cygport accordingly.

P.S. I'll be mostly AFK until Monday.


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
Last set of questions (and yes, I'm really not an expert): Why can
Fedora/RHEL use x86_64-redhat-linux as canonical triplet, and why has
Fedora/RHEL apparently no problems with that?

It is only so far as binutils/gcc/gdb are concerned, otherwise it's
x86_64-unknown-linux-gnu. We should be able to handle things like that
as well: x86_64-pc-cygwin for the toolchains (native and cross) but
leave config.guess alone (x86_64-unknown-cygwin), which by itself
isn't all that visible. I just need to adjust cygport accordingly.
P.S. I'll be mostly AFK until Monday.

Ok, thank you. Have a nice weekend!


Corinna

[Earnie Boyd]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
Last set of questions (and yes, I'm really not an expert): Why can
Fedora/RHEL use x86_64-redhat-linux as canonical triplet, and why has
Fedora/RHEL apparently no problems with that?

It is only so far as binutils/gcc/gdb are concerned, otherwise it's
x86_64-unknown-linux-gnu. We should be able to handle things like that
as well: x86_64-pc-cygwin for the toolchains (native and cross) but
leave config.guess alone (x86_64-unknown-cygwin), which by itself
isn't all that visible. I just need to adjust cygport accordingly.

Reading this conversation leads to a question in my mind. Can't
cygwin.sc.in be adjusted to use @TARGET@ for the triplet and let the
configure process take care of it?

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)
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 :-)

Btw!

Even with this change to the size of sszie_t, we have a *very* good
chance that our installations still work. The reason is a curious
behaviour of the x86_64 CPU when using 32 bit register writes:

Every time, a 32 bit value is transfered into a register, the upper 32
bit are zeroed out:

before: rax == 0x123456789abcdef

movl #0x42, %eax

after: rax == 0x42

Consider that the first four arguments to a function are always stored
in registers ($rcx, $rdx, $r8, $r9), and consider that return values up
to 64 bit are returned in $rax.

==> There's a good chance we don't see a big difference.

I, just tested to run the "old" tcsh in mintty with the "new" Cygwin
DLL and everything still appears to work.


Corinna