From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id 8EF78384B106 for ; Tue, 15 Dec 2020 12:06:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8EF78384B106 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1M597s-1kqF1i48bE-001Cd9 for ; Tue, 15 Dec 2020 13:06:27 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5CF8CA82BD5; Tue, 15 Dec 2020 13:06:26 +0100 (CET) Date: Tue, 15 Dec 2020 13:06:26 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Failure during build of Python 3.8 via cygport Message-ID: <20201215120626.GB4560@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:0ZBYfs4xhnypOcbfS4/y95WRKOJRqHBHxT++0Wz+eiOvA4OJ9Ar Tb3tAg47B4AUpk3p2O/IZYShiFKf4653cHMs38c1epRALZZOedDhEuKn4vj/4d98L2f/snU 5kw2+oO2QXFmzkT4BlwBh82DqC4hSVGbKDKTa4L8TWRnvwzgvjwyVPYiKydsvqAkHE7P6TL /urOhw8H/zTXl/JDjGypw== X-UI-Out-Filterresults: notjunk:1;V03:K0:4PEv5ueh09w=:xC/XJ/Haz+p82LrjISudIc 0JjvHYsUfuovoVa8BlyWAFi1C+WTqPgLMyjDHfNLSnWpwq5c0Eog64cIw49sR2l9lquhCZ08M 2QT4y8latrKg3mKlu6yeLPWgwyX3DBnMImYbasUs/+fxEiS1+bs+L564u48HUa+2l5Rvg2ct2 hn5r6CTF4fM0c1kmaQm5l36/mN/LJ0Ed75xsGEudcQtlefbWF/Kvuwb10Xiozh2hfybvLthpc JA1hLcFC2zjVpZaWg3iEVUQGG0wtDaDoih47jFsHu1H+arb5emJ/18stQOvcC7y+Xgo8GHgHX ZuS3K3jVd+2ZDceEuFynM1tb58SQVJ+XncD+ibqc+Yet/HPfKEderux8TrfC5Bx9E5GS1Lhjb NQoRx3T9+ykEkPzYfytVQO5a9ufcKNgtrhJjoGeOJ3M500Nr5G8ER+UARxMUDpOn8JW8Yl2d6 dTZstF/+/A== 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:06:30 -0000 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. Corinna