Ken Brown via Cygwin wrote:
On 3/5/2021 8:45 PM, Takashi Yano via Cygwin wrote:
On Fri, 5 Mar 2021 17:30:30 +0100
Marco Atzeri wrote:
On 05.03.2021 15:42, Corinna Vinschen via Cygwin 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"!
Corinna
Python has a lot of problem but not this one for what I can see
$ python3.8 /usr/lib/python3.8/test/pythoninfo.py | grep uname
os.uname: posix.uname_result(sysname='CYGWIN_NT-10.0-19041-WOW64',
nodename='LAPTOP-82F08ILC', release='3.1.7-340.i686',
version='2020-08-22 19:03 UTC', machine='i686')
and similar for the other version
I also tried to build python 3.8.7, 3.8.3 and 3.7.9 under cygwin 32bit
and 64bit current git head with the commit 532b91d2 reverted. All trials
resulted in success. Moreover, os.uname() works expectedly.
That is, the problem reported by Mark could not be reproduced.
https://cygwin.com/pipermail/cygwin-apps/2020-December/040765.html
Updating something other than cygwin1.dll might fix the issue???
I wonder if Mark had a corrupt libcygwin.a installed at the time he encountered
this problem. That would explain his observations, except for the claim that
python was calling uname via dlopen/dlsym. I guess he's rechecking that claim.
Mark, FWIW, I looked at the git history of python's Modules/posixmodule.c, and I
can't see where they ever did this.
I must be mistaken. I appreciate everyone's help and patience while I tried to
reproduce what I (thought I) was seeing last December. I'm going to stand down on
this topic as I think I'm only adding noise. Please proceed on Corinna's course.
Thanks & Cheers,
..mark
--
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
