From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-apps@cygwin.com
Subject: Re: Failure during build of Python 3.8 via cygport
Date: Sun, 13 Dec 2020 14:59:58 -0700 [thread overview]
Message-ID: <faf62132-5f8a-9b5d-0332-b09ca7d0758b@SystematicSw.ab.ca> (raw)
In-Reply-To: <1fea201e-4787-4d58-f809-07613c3f73fa@gmail.com>
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.]
prev parent reply other threads:[~2020-12-13 22:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 8:14 Mark Geisert
2020-12-12 6:33 ` Mark Geisert
2020-12-13 8:52 ` Mark Geisert
2020-12-13 14:34 ` Marco Atzeri
2020-12-13 21:59 ` Brian Inglis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=faf62132-5f8a-9b5d-0332-b09ca7d0758b@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).