Title: utimes() functions fail with ENOSYS even when detected by configure
Type: compile error Stage: resolved
Components: Build Versions: Python 3.3
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bkabrda, neologix, richmose
Priority: normal Keywords: patch

Created on 2012-07-25 16:50 by richmose, last changed 2013-03-03 17:58 by neologix. This issue is now closed.

File name Uploaded Description Edit richmose, 2012-07-25 16:50 A diff against the from the source archive.
Messages (5)
msg166413 - (view) Author: Richard Moseley (richmose) Date: 2012-07-25 16:50
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: Function not implemented' is given and the installation halts.

This problem has been tracked down to the fact that some of the utimes() functions will return ENOSYS rather than the expected result.

I have now patched the script to check for the seven variants of the function, which is attached. This patch would ideally have made use of the same model as the AC_CHCEK_FUNCS macro but this would require adding a new file to the source tree.
msg180123 - (view) Author: Bohuslav "Slavek" Kabrda (bkabrda) * Date: 2013-01-17 11:28
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/ -> /builddir/build/BUILDROOT/python33-python-3.3.0-3.el6.i386/opt/rh/python33/root/usr/lib/python3.3/lib-dynload
[?1034herror: Function not implemented

I tracked it down to distutils calling os.utime. When I comment the two lines [1] that use utime, everything works fine (well, except all the tests using utime fail, too). I'm running RHEL 6.4. Any chance to fix this? Richard's patch doesn't work for me.


msg180150 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) Date: 2013-01-17 19:53
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 like the idea of adding explicit check for this, because any syscall can fail with ENOSYS (we've had recently pipe2(), accept4(), etc).
It's really a distribution issue.

For the second one, it seems that RHEL6.4 doesn't have utime() anymore, which I find really strange (although POSIX.1-2008 marks utime() as obsolete).
Could you provide the output of:
$ strace ./python -c "import os; os.utime('.')"
msg180179 - (view) Author: Bohuslav "Slavek" Kabrda (bkabrda) * Date: 2013-01-18 07:59
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 confusion.

msg183391 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) Date: 2013-03-03 17:58
Alright, closing.
Date User Action Args
2013-03-03 17:58:22neologixsetstatus: open -> closed
resolution: not a bug
messages: + msg183391

stage: resolved
2013-01-18 07:59:23bkabrdasetmessages: + msg180179
2013-01-17 19:53:54neologixsetnosy: + neologix
messages: + msg180150
2013-01-17 11:28:56bkabrdasetnosy: + bkabrda
messages: + msg180123
2012-07-25 16:50:07richmosecreate