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 EEC2D385800D for ; Tue, 15 Dec 2020 08:06:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EEC2D385800D 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 0BF86IlP026915 for ; Tue, 15 Dec 2020 00:06:18 -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 smtpdMe0Z0x; Tue Dec 15 00:06:09 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> <0f498c92-409b-6ac8-d0ba-93ac753ab4b8@maxrnd.com> <20201214113300.GA4560@calimero.vinschen.de> From: Mark Geisert Message-ID: Date: Tue, 15 Dec 2020 00:06:09 -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: <20201214113300.GA4560@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, 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: Tue, 15 Dec 2020 08:06:22 -0000 Hi Corinna, Corinna Vinschen via Cygwin-developers wrote: > On Dec 14 02:42, Mark Geisert wrote: [...] >> 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. [...] >> '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? > > No, it isn't. The old uname entry point is still required for old > applications built prior to API version 335. If you build a new > application it will actually call uname_x when it tries to call uname > since that's how the libcygwin.a layer translates it. > > It's a bit unfortunate that uname_x is exported by libcygwin.a > as well (in theory it should only export uname, pointing to uname_x > in the DLL), but this is how it always was, as you can see in > the 32 bit build with symbols only available there, e. g. aclcheck: > > $ nm libcygwin.a | grep aclcheck > 00000000 I __imp___aclcheck > 00000000 I __imp___aclcheck32 > 00000000 I __imp__aclcheck > 00000000 T __aclcheck > U __imp___aclcheck > 00000000 T __aclcheck32 > U __imp___aclcheck32 > 00000000 T _aclcheck > U __imp___aclcheck32 > > In retrospect, uname_x should be named _uname_x or so, with a leading > underscore, so as not to pollute the namespace, but either way, that > isn;t your problem. OK, I see. > The problem here might be that you get the old uname function if > you dlopen the cygwin dll and dlsym(hdl, "uname"). Is that the > case in python? Yes it is. > If so, I have a simple, dirty workaround below. Can you check if that's > the problem, please? A new Cygwin DLL built with your patch does correct this 'uname' issue when building Python. Wonderful! Thank you very much! ..mark