Ned Deily <[email protected]> added the comment:
Thanks Garrett for reporting the problem and thank Nick for the patches. It
turns out the problem is more involved though the solution is similar. I've
spent some time figuring out what went wrong here and documenting it in this
issue so that no one else has to. Ugh.
The relevant checkin events:
(1) (2009-07-16) r74038 changed the autoconf tests for chflags and lchflags to
be m4a double-quoted (from '[' to '[[') to "ensure they don't get mangled".
The test continues to use the AC_TRY_RUN macro and is working correctly.
(2) (2009-11-02) r76050 checked in a modified version of a patch from Gentoo to
help support cross-compiling. The original patch was against a pre-r74038
version; it wrapped the AC_TRY_RUN macro in an AC_CACHE_CHECK and a layer of
quotes. In updating the patch for the then-current trunk (2.7), the
significance of the r74038 change was apparently overlooked, resulting in an
extra and faulty level of [...] quotes which end up in the configure test C
source. The test now gets compile errors on all Unix-y platforms but it is
only significant on those that do support chflags and/or lchflags, i.e. BSD
ones and OS X.
(3) (2010-01-30) The buggy test from trunk is merged into py3k (3.2) r77862,
3.1 r77863, and 2.6 r77864.
(4) (2010-05-08) As part of Issue8510 updates to configure.in to work with
autoconf 2.65, r80478 for py3k (3.2) and r80969 for trunk (2.7) converted the
AC_TRY_RUN macro calls to ones using AC_RUN_IFELSE and AC_LANG_SOURCE. An extra
level of quoting is added to preserve the existing, albeit buggy syntax. The
net effect is that the configure test C code generated is the same and still
always fails with a compile error.
While I have not tested this on any BSD-like systems other than OS X, I believe
this means that os.chflags and/or os.lchflags have been missing-in-action from
builds on OSes where they should be supported for the following releases (i.e
since 2009-11-02):
2.6.5
2.6.6
2.7
3.1.2
3.2a2
A side note for OS X: Apple first introduced lchflags() support in OS X 10.5.
Since the python.org OS X installer pythons are traditionally built to an
10.3/10.4 ABI, none of the OS X installers for the above Python releases would
have had os.lchflags anyway (only os.chflags), except for the new 2.7
32-bit/64-bit installer if the 2.7 test weren't otherwise broken.
The solution is to fix the buggy configure.in macros along the lines suggested
by Nick. I have created and tested three new patches to do this:
issue8746-py3k.patch for py3k (3.2a2+)
issue8746-27.patch for release-27-maint (2.7+)
issue8746-31.patch for release-31-maint (3.1.2+)
A variant of the 3.1 patch should apply to release-26-maint (2.6.6+) however
2.6 is now in security-fix-only mode.
In each case, the patch only modifies configure.in. It is necessary to run
autoreconf after applying and before checkin. A simple test of the fix is to
do ./configure before and after:
$ rm -f config.log config.status
$ ./configure
$ grep "expected identifier or '(' before " config.log
conftest.c:191: error: expected identifier or '(' before '[' token
conftest.c:200: error: expected identifier or '(' before ']' token
conftest.c:191: error: expected identifier or '(' before '[' token
conftest.c:200: error: expected identifier or '(' before ']' token
$ patch <issue8746-[...].patch
$ autoreconf
$ rm -f config.log config.status
$ ./configure
$ grep "expected identifier or '(' before " config.log
$
Note that I have not attempted any cross-compiling testing either with or
without the patches.
----------
nosy: +doko, gregory.p.smith
priority: normal -> release blocker
stage: unit test needed -> patch review
title: *chflags detection broken on FreeBSD 9-CURRENT -> os.chflags() and
os.lchflags() are not built when they should be be
Added file: http://bugs.python.org/file18837/issue8746-py3k.patch
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue8746>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
