From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by sourceware.org (Postfix) with ESMTPS id 5F82B384B821 for ; Tue, 15 Dec 2020 12:14:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F82B384B821 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MfqGN-1k9UsC20i1-00gFOo for ; Tue, 15 Dec 2020 13:14:01 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id EB293A82BD5; Tue, 15 Dec 2020 13:14:00 +0100 (CET) Date: Tue, 15 Dec 2020 13:14:00 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Failure during build of Python 3.8 via cygport Message-ID: <20201215121400.GC4560@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-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> <20201215120626.GB4560@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201215120626.GB4560@calimero.vinschen.de> X-Provags-ID: V03:K1:zqQ4TUhro6CXkC8l2OJGZ2UO3GQ/yAcGCl3kydmeS7Hd+k2wZK5 PGH/h8fzams1O9gZf9ig9yp0ZTLT/cM3wOlHNhyJUnF6aLVS/4Sm3pLDs6VuAh2dcFBRasR Ke4U8aPOlAKz0VkrubrcntqtrbpCUV5yFILMKQi62OBxJIpXsL7GJVg1yPmDFrzzdZOretE N6UMgwHqcEPj40M1V/gIg== X-UI-Out-Filterresults: notjunk:1;V03:K0:s5Mt9KhTzUA=:dZBqEGZWymG78SAcxP81gS n8Ofc8VHhM9sl9TnESxLNEYDT0Zbm6mdfTVUX1JjVP3y3TI3zY8FiP71VORkuX4egn6X41QAr mljN+g1aAB032mbrXa99WH3ua9HMXNO3YgaGiQ1AvgCNwGtgUI3keCM/jUFbQL66aQbiWz+f/ geMVxTmFoB9EKNPilX7sz5pHJ5rrI7md5It6EHPK/24UFPwVqCbjB2N1qowDltQ4noJtBK+AV RLYvZf3rQxUWzhCwJ45Vobe8VLPcWoHmWvWLVy9H7AOamLcIrZdhkM5QdygM843BEKaPXtF35 sKwDhgwkkJm3+7MJZom0eXyJlj9MDPVfCISaDNHgBQtOdVp6t9+f+n5YkhN01UshCrfC+UF1W iRLupwI5cZb6OdgzqA8RzChUIss3St4KJpoOd1uBKtbe3YmXYeewwUEUnYmdpvRf8CASy6Isk F5PtzZZ11A== X-Spam-Status: No, score=-101.0 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham 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 12:14:04 -0000 On Dec 15 13:06, Corinna Vinschen via Cygwin-developers wrote: > On Dec 15 00:06, Mark Geisert wrote: > > 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! > > Great, thanks for testing and confirming! I pushed the patch. I created new developer snapshots. Corinna