Changes by Barry Davis <barry_da...@stormagic.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Barry Davis added the comment:
I think this is the same issue I'm getting.
I'm hitting it when compiling python 3.6.2 compiled with gcc-4.8.4.
This wasn't occasional, it was every time I tried.
As a feeble workaround I was compiling in parallel, then in serial when it
fails, although I'm now
Barry Davis added the comment:
I meant my cross compiled python, not my cross compiler.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry Davis added the comment:
Looks like I was mistaken. My cross compiler was trying to load libgcc_s.so.1
from the standard location and not liking the one it found. Fixed for now by
setting LD_LIBRARY_PATH to point at the dir containing the right libgcc_s.so.1
--
versions
Barry Davis added the comment:
I've just hit this issue using Python-2.7.9, gcc-8.1.0, glibc-2.23.
The patch I made to fix the issue based on comments in this issue:
--- Python-2.7.9/setup.py 2019-01-25 09:30:39.049501423 +
+++ Python-2.7.9/setup.py 2019-01-25 09:30
Barry Davis added the comment:
The behaviour I saw (32-bit only) was a python process getting stuck.
I got this from strace:
...
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
New submission from Barry Davis :
This bug exists again: https://bugs.python.org/issue1521375
In ctypes/util we defend against gcc removing /dev/null by using a temp file,
but similar code for ld still uses /dev/null, resulting in it removing
/dev/null if it has permission, i.e. if running
