Mike Frysinger <vap...@users.sourceforge.net> added the comment:
the chflags is specifically documented as needing a runtime test:
# On Tru64, chflags seems to be present, but calling it will
# exit Python
which is why i left the default of AC_TRY_RUN but cross-compile falls
back to a simple link test. btw, a compile test is not valid when
trying to see if a function exists. you'll get a successful compile
(and warning about implicit function), but no error because you didnt
finally link the object with the undefined reference.
somewhat similar are the compiler checks (profile/pthread/alias/etc...).
some compilers do different things when linking and compiling (like gcc
and -pthread), so sticking to a LINK in the fallback of the RUN is
better, although not always perfect. some flags are accepted/ignored by
compilers and issue only warnings about the unknown flags, not errors.
but this issue probably isnt worth worrying about considering the code
in there today suffers from this edge case (and if no one is
complaining, then forget about it).
in terms of making sure all AC_TRY_RUN's have cross-compile fallbacks, i
only worried about the ones that actually get exercised. the two i
posted fixes for are the only ones ive seen people (and myself) actively
hit.
the ipv6 should def have a LINK fallback, and it should try using
in6addr_any as that is often an exported symbol (which is missing when
ipv6 doesnt exist).
the double endian checks could easily be made into a compile test with a
creative grep. pick a double value that expands into a funky ascii
string and then grep the object file for a match. otherwise, a char
swapped ascii string indicates it's big endian.
the wchar/rshift signed tests can be made into a compile-only test by
creative use of arrays (like autoconf does now with compile sizeof() tests).
main() { char foo[(((wchar_t) -1) < ((wchar_t) 0)) ? 1 : -1]; }
compilers will portably abort when array size is negative, and this
expression should be a constant.
i dont think any of the "broken" ones need to be sorted out as they
already have cross-compile fall backs and there isnt much to be done in
figuring out if the run time env is broken.
thanks Greg for the commits !
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
