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 7C9173858009 for ; Fri, 5 Mar 2021 09:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C9173858009 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 1259Bj0h092497 for ; Fri, 5 Mar 2021 01:11:45 -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.20]" via SMTP by m0.truegem.net, id smtpdr14iX4; Fri Mar 5 01:11:39 2021 Subject: Re: segfault on 32bit cygwin snapshot To: cygwin@cygwin.com References: <9d7b9dc2-cb92-498b-7655-e9c618114c87@gmail.com> <20210221072954.db2dcbd523ed366e4dfcb0d0@nifty.ne.jp> <7480c946-8e02-aba2-c06f-6b39f630699f@gmail.com> <20210301095546.dce31a474bd0cec2c3518f87@nifty.ne.jp> <20210301212542.8b1749f92af62c01b008f25a@nifty.ne.jp> <20210302200308.62db4fe01f78fb35a538784f@nifty.ne.jp> <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp> <20210304180534.7c3825e6ee989a2bf62f0652@nifty.ne.jp> <20210304205000.4ac34afe1a8b767ea2986291@nifty.ne.jp> <98df59b3-a139-03d2-c8c5-31ff4f8448ab@gmail.com> <625cb9d2-b6cc-3ada-eea9-44a5e73da17c@gmail.com> From: Mark Geisert Message-ID: <72a86908-e150-2070-24f7-79ca82de9916@maxrnd.com> Date: Fri, 5 Mar 2021 01:11:40 -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: <625cb9d2-b6cc-3ada-eea9-44a5e73da17c@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 09:11:49 -0000 Marco Atzeri via Cygwin wrote: > On 04.03.2021 21:17, Marco Atzeri wrote: >> On 04.03.2021 16:17, Ken Brown via Cygwin wrote: >>> On 3/4/2021 6:50 AM, Takashi Yano via Cygwin wrote: >>>> On Thu, 4 Mar 2021 12:11:11 +0100 >>>> marco atzeri wrote: >>>>> I have no problem to patch Python to solve the issue, >>>>> but I have not seen evidence of the dlsym mechanism . >>>>> But of course I an NOT and expert in this field. >>>>> >>>>> If someone looking to the code can give me some hints, >>>>> I will appreciate >>>> >>>> I am also not sure where the dlsym() is used in python. >>>> At least, os.uname() works in python 3.8.7 and 2.7.18 in my >>>> environment even without that snippet. It seems that os.uname() >>>> does not use dlsym(). Do I overlook something? >>> >>> This all started because Mark reported a problem building python 3.8.3: >>> >>>    https://cygwin.com/pipermail/cygwin-apps/2020-December/040765.html >>> https://cygwin.com/pipermail/cygwin-developers/2020-December/012019.html >>> >>> It's strange that Marco never bumped into the problem. >>> >>> Ken >> >> I never built python using cygwin snapshots as Mark was trying to do, >> all my builds were using 3.1.7. >> >> Let me set a separate enviroment for building on latest snapshot > > I can not replicate with latest snapshot > > $ uname -svr > CYGWIN_NT-10.0-WOW 3.2.0s(0.340/5/3) 2021-03-01 15:42 > > nor in 64bit when building 3.8.8 > > For what I see the DLL is always using a proper import > from cygwin1.dll > > $ objdump -x libpython3.8.dll |grep uname >         2b9de0   2170  uname >         2b9de8   2171  uname_x > > the only thing not standard on my build system is a case sensitive > filesystem and mount I had concerns that I had somehow corrupted my build environment, and it was Marco's successes that convinced me to reinstall 3.1.7 to recover a known-good environment. Then seeing Marco go ahead and release the different Python releases (yay!) I didn't investigate any further. I'm now trying to locate the os.uname usage of dlopen/dlsym again just for the record but am having some difficulty. I'll reply again when I've got it. Thanks all, ..mark