Ned Deily <n...@acm.org> added the comment: I agree that adding the definitions of HAVE_GCC_ASM_FOR_X87 to pymacconfig.h solves the problem.
[mini-rant on] This problem is another illustration of how easy it is to inadvertently introduce significant bugs in the OS X multi-architecture support, bugs which can currently go undetected without a lot of diligence on everyone's part. We were lucky on this one. Thanks, Sridhar. [mini-rant off] After digging around a lot, I see now why I hadn't noticed it before. Always specifying --enable-universalsdk=/Path/To/sdk and default arch options (as the current installer builds do) causes configure to include -arch ppc and -arch i386 in CFLAGS and these get added to the gcc call in autoconf tests AC_TRY_COMPILE and AC_TRY_RUN. That meant the autoconf test for HAVE_GCC_ASM_FOR_X87 was *always* NO because the PPC arch compile always failed on the Intel assembler code test. And the compile failure is not obvious unless you examine configure.log in detail and notice that the result of the test was NO because of the multiple architectures. If configure is called with just --enable-universalsdk (no path) but on 10.5 or 10.6, the multiple archs still get added to CFLAGS, the test returns NO again, and the problem is still masked: CFLAGS='-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - g -O2' But if you make that same configure call on 10.4, the multiple archs are not added: CFLAGS='-g -O2' On a 10.4 PPC system (my case) the test *still* returns NO so the problem is *still* masked. It's only if you run the build with that configure on a 10.4 i386 system that the test will pass, causing HAVE_GCC_ASM_FOR_X87 to finally be defined. Then, during the make of the multi-architecture build, the root problem will finally be exposed, as it was here. That also means that, for multi-arch builds on OS X, the X87 control word code would never be used in the python.org installers or any other intel/ppc multi-architecture build. I hope that is a reasonably close to correct analysis but I could have a few details wrong. It's clearly easy to get wrong. Looking elsewhere in configure.in, there are other architecture-specific run-time tests that could give incorrect results in a multi-arch environment. The math tests immediately following appear to take a conservative approach so I'm guessing that, if there were conflicting results during the multiple arch compiles and runs, the code would work correctly though possibly sub-optimally. I didn't see any other obvious incorrect results although it is difficult to tell when so many configure tests get compile or build errors by design. There seem to be at least two issues brought out here: 1. How to make core developers and patch contributors more aware of the special requirements of multi-architecture builds? 2. What, if any, additions or changes to tests and testing process should be made to help catch problems like this (and others that might be lurking)? At a minimum, I would like to see a message added to configure.in that is output on OS X to warn that some of the autoconf derived values for architecture-specific SIZEOF and processor features are overridden in Include/pyconfig.h. Currently there doesn't seem to be any reference to this in configure.in and it so easy to be misled by the autoconf results. Adding comments to the source of the overridden tests would be great but a bit of work. Conditionally skipping the tests would be even better, if it could be made to work. A more systematic test process would also help. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7452> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
