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

[richmose]

BPO	15448
Files	configure.ac.diff: A diff against the configure.ac from the source archive.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-03-03.17:58:22.768>
created_at = <Date 2012-07-25.16:50:07.245>
labels = ['build', 'invalid']
title = 'utimes() functions fail with ENOSYS even when detected by configure'
updated_at = <Date 2013-03-03.17:58:22.766>
user = 'https://bugs.python.org/richmose'

bugs.python.org fields:

activity = <Date 2013-03-03.17:58:22.766>
actor = 'neologix'
assignee = 'none'
closed = True
closed_date = <Date 2013-03-03.17:58:22.768>
closer = 'neologix'
components = ['Build']
creation = <Date 2012-07-25.16:50:07.245>
creator = 'richmose'
dependencies = []
files = ['26514']
hgrepos = []
issue_num = 15448
keywords = ['patch']
message_count = 5.0
messages = ['166413', '180123', '180150', '180179', '183391']
nosy_count = 3.0
nosy_names = ['neologix', 'bkabrda', 'richmose']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue15448'
versions = ['Python 3.3']

[richmose]

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 configure.ac 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.

[bkabrda]

I have a similar problem with python 3.3.0. During installation, I get

<snip>
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/_codecs_cn.cpython-33dm.so -> /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
</snip>

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.

Thanks.

[1] http://hg.python.org/cpython/file/f3e348ab08c6/Lib/distutils/file_util.py#l149

[neologix]

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('.')"

[bkabrda]

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.

[1] http://fedoraproject.org/wiki/Projects/Mock

[neologix]

Alright, closing.