From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id D3257386F416 for ; Mon, 14 Dec 2020 10:42:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D3257386F416 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 0BEAgcOu037105 for ; Mon, 14 Dec 2020 02:42:38 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdLPXgYg; Mon Dec 14 02:42:30 2020 Subject: Re: Failure during build of Python 3.8 via cygport To: cygwin-developers@cygwin.com References: <758d2138-587b-2970-6c35-69d5c655a598@maxrnd.com> From: Mark Geisert Message-ID: <0f498c92-409b-6ac8-d0ba-93ac753ab4b8@maxrnd.com> Date: Mon, 14 Dec 2020 02:42:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <758d2138-587b-2970-6c35-69d5c655a598@maxrnd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 10:42:43 -0000 [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