On 2020-12-13 07:34, Marco Atzeri via Cygwin-apps wrote:
On 13.12.2020 09:52, 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.
That was nearly two years ago.
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.
I'll move this discussion over to the developers list tomorrow.
uname(2):
NOTES
...
The length of the fields in the struct varies. Some operating
systems or libraries use a hardcoded 9 or 33 or 65 or 257. Other
systems use *SYS_NMLN* or *_SYS_NMLN* or *UTSLEN* or *_UTSNAME_LENGTH*.
Clearly, it is a bad idea to use any of these constants; just use
*sizeof*(...). Often 257 is chosen in order to have room for an
internet hostname.
...
C library/kernel differences
Over time, increases in the size of the /utsname/ structure have led to
three successive versions of *uname*():
/sys_olduname/() (slot /__NR_oldolduname/),
/sys_uname/() (slot /__NR_olduname/), and
/sys_newuname/() (slot /__NR_uname/).
The first one used length 9 for all fields;
the second used 65;
the third also uses 65 but adds the domainname field.
The glibc *uname*() wrapper function hides these details from
applications, invoking the most recent version of the system call
provided by the kernel.
thanks for the analysis
let me know if you think we should correct the python build in any way
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
