[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-03-03 Thread Charles-François Natali
Charles-François Natali added the comment: Alright, closing. -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker ___ __

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Bohuslav "Slavek" Kabrda
Bohuslav "Slavek" Kabrda added the comment: Ouch, the problem was in fact on my side. I was building python inside a mock [1] chroot that had different version of headers than the actual kernel. When I figured this out and made the versions the same, everything passed perfectly. Sorry for the c

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Charles-François Natali
Charles-François Natali added the comment: There are actually two distinct issues. For the first one, the problem is really a distribution issue: the libc is more recent than the kernel, and exports *utimes() whereas the kernel doesn't implement those syscalls, which results in ENOSYS. I don't

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2013-01-17 Thread Bohuslav "Slavek" Kabrda
Bohuslav "Slavek" Kabrda added the comment: I have a similar problem with python 3.3.0. During installation, I get running install_lib creating /builddir/build/BUILDROOT/python33-python-3.3.0-3.el6.i386/opt/rh/python33/root/usr/lib/python3.3/lib-dynload copying build/lib.linux-i686-3.3-pydebug

[issue15448] utimes() functions fail with ENOSYS even when detected by configure

2012-07-25 Thread Richard Moseley
New submission from Richard Moseley : When building on a ASUS Eee PC 1000 running the original Xandros O/S with libc-2.7-13, the various utimes() functions are being detected as available for use, everything compiles. However, during installation of the lib-dynload libraries, the error 'Error: