On Mar 8 03:07, Mark Geisert wrote: > Following up to myself... > > Mark Geisert wrote: > > Hi Corinna, > > > > On Fri, 5 Mar 2021, Corinna Vinschen wrote: > > > On Mar 5 01:11, Mark Geisert wrote: > > > > 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. > > > > > > Guys, > > > > > > if it turns out that we fixed a problem that doesn't actually is a > > > real-world problem, I'm wondering if we shouldn't just revert the Cygwin > > > patch we're talking about here (commit 532b91d24e9496) and be done with > > > it. > > > > > > Special casing dynamic loading of uname just to support some experimental > > > bordercase doesn't make much sense. In that case I'm all for "don't do > > > that"! > > > > That may well be the appropriate endpoint, but please let me dig a > > little further into the recent Python versions. The fact that they had > > an explicit dlopen/dlsym to get at uname(), but now they don't, troubles > > me. I want to be sure us Cygwin folk aren't in an inadvertent "arms > > race" with the Python devs over the uname API change. Dunno why this > > didn't occur 15+ years ago, but here we are. > > > > I think it was in Python's Modules/posixmodule.c. They're certainly > > using uname() directly in their most recent builds. But I believe that > > wasn't always the case, even just a few months ago. Let me dig for a > > day or two. > > Not to put too fine a point on it, but I now believe I hit the issue I > reported due to my own corrupted build environment. Marco and Ken have both > built recent Python packages on Cygwin 3.1.7 and proto-3.2.0 respectively, > Ken having reverted the commit you're talking about (not sure about Marco). > Both had success. > > I believe reverting that commit 532b91d24e9496 is the correct action to take.
Did so this morning. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple