Re: Failure during build of Python 3.8 via cygport

[Mark Geisert <mark@maxrnd.com>]

[Bringing this thread over from cygwin-apps...]

Mark Geisert wrote:
> Mark Geisert wrote:
>> This seems to be a problem setting up a platform-specific build directory. The 
>> sysconfig.py script wants to use "lib." + platform + pythonversion but the 
>> platform string somehow gets corrupted into non-utf8 bytes.  For instance, 
>> building Python 3.8 comes up with:
>>      lib.cygwin-\365\377\377o-\377o-3.8
>> as the directory name.  Broken, but could work.  The build failure happens 
>> because the script tries to write this directory name into a file but it's not a 
>> valid utf8 string.  The directory name should have been:
>>      lib.cygwin-3.2.0-x86_64-3.8
> 
> And the corruption is due to something about a recent change to the operation of 
> Cygwin's uname() function.  The change was introduced in Cygwin API version 335; 
> I'm running 340 on my test machine.  This being a fairly recent change might 
> possibly explain why nobody else has run into this issue yet.
> 
> Basically, os.uname within Python is calling Cygwin's uname() passing the address 
> of a buffer declared to be 'struct utsname'.  The structure layout changed in API 
> 335.  What I've hit is a mismatch between what Python expects and Cygwin delivers.

Brian Inglis pointed out the API 335 change was made a couple years ago, so strike 
the quoted conjecture about why nobody else has hit this.  A new conjecture follows...

Debugging Python's os.uname showed Cygwin's uname() being called with a 'struct 
uname' as defined in /usr/include/sys/utsname.h, which is fine.  But it's the 
"old" pre-335 uname() interface being called, not the "new" 335+ interface 
uname_x().  Note that the famous 'mkimport' script, used when building the Cygwin 
DLL, has an arg "--replace=uname=uname_x" which I believe is supposed to equate 
the two names so the code in uname_x() is called whether the interface is 
uname_x() or uname().  That's not happening.

My first thought was, dang it, my "optimizations" of mkimport broke it.  But 
that's not the case.  Restoring a previous version of mkimport doesn't help.

'nm' shows that both uname and uname_x exist in libcygwin.a and also cygdll.a. 
And a newly-created Cygwin DLL has both functions, with different addresses.
That's wrong, isn't it?

..mark