Output of "uname -s" and "uname -o"
Tue Jun 10 15:50:00 GMT 2008
On Tue, Jun 10, 2008 at 10:56:14AM -0400, Igor Peshansky wrote:
>On Tue, 10 Jun 2008, Christopher Faylor wrote:
>> Maybe it isn't clear. This may be new territory to you but we have
>> already done things like changing the size of a structure by using
>> #define (and other) trickery in Cygwin even before transitioning from
>> stat64 to stat. You also need a new function, of course.
>Right. It's not new territory at all -- I know it's been done in Cygwin
>before, so I don't quite understand why the issue of changing the size of
>the struct keeps coming up.
Once again: 1) Neither Corinna or I think this is a big problem and 2)
It changes externally visible behavior which people rely on.
You are characterizing this as an issue which flares up and dies down
without resolution. That is not the case.
>>I haven't seen any good explanation of how you'd deal with any
>>application which is relying on the current behavior since you'd be
>>breaking externally visible backwards compatibility. That's the
>>difference between changing the structure size for uname versus
>>changing the structure size for stat or terminfo.
>By the current behavior you mean the fact that the underlying Windows
>information is appended to the sysname field? In one of my previous
>messages I suggested adding a CYGWIN-env flag to force the old
We add settings to the CYGWIN variable only very grudgingly and I can't
see how this would be a good idea in this case. If you released a
program or script which relied on this behavior you'd have to tell every
user to set the environment variable or (ick) set the environment
variable in the program itself.
The mailing list would be filled with
>I try build blorp and it say unable to guess system type. I reinstall
>five times but still doesn't work. blorp not build cygwin?
Read the FAQ! This was mentioned an hour ago in this mailing list.
More information about the Cygwin-developers