| msg92067 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-08-29 20:30 |
| Building Python 2.6.2 on Mac OS X 10.6 (final version, 10A432) fails. Full build transcript is attached. Other system details: Xcode 3.2, hardware is MacPro1,1 |
|
|
| msg92070 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2009-08-29 21:07 |
| This also applies to trunk, py3k and release31-maint. |
|
|
| msg92074 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2009-08-30 01:41 |
| For those trying to debug this, to silence the math.h warnings, set MACOSX_DEPLOYMENT_TARGET to 10.6 or something. |
|
|
| msg92075 - (view) |
Author: Jesse Noller (jnoller) * |
Date: 2009-08-30 01:45 |
| 3k and trunk compile fine for me. Clean snow leopard install. My first suggestion is nuking macports. |
|
|
| msg92076 - (view) |
Author: Jesse Noller (jnoller) * |
Date: 2009-08-30 02:20 |
| 2.6.2 maint compiles fine too - again, with a clean install of Snow Leopard, no macports. |
|
|
| msg92077 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-08-30 02:33 |
| Note that this problem appears to be x86_64-specific (caused by "- arch_only i386"), and only happens if you configure with --enable- framework. |
|
|
| msg92082 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2009-08-30 06:48 |
| As Jeese points out, there are suspicious signs of MacPorts in the log: "/opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.6" Try removing all /opt/local entries from your $PATH and try again with export MACOSX_DEPLOYMENT_TARGET=10.6 |
|
|
| msg92083 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-08-30 07:28 |
| The default value for the -arch flag changed in SL. It used to be the same as the output of the arch command (i386 on intel systems) and now is x86-64. I'll create a patch for configure to automaticly detect the right value. As a workaround you can build a universal build (--enable- universalsdk=/) |
|
|
| msg92088 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-08-30 14:25 |
| Noting for completeness that: * 3.0.1 behaves the same as 3.1.1 (works without --enable-framework). * 2.5.4 fails with 'cc1: error: unrecognized command line option "-Wno- long-double"'. Once this is removed from the configure script, it then fails in mactoolboxglue.c due to missing Carbon functions, whether or not it was configured with --enable-framework. Using --disable-toolbox- glue and not using --enable-framework allows the build to succeed. Using --disable-toolbox-glue and --enable-framework causes a failure involving struct rusage in posixmodule.c. Adding "#define _DARWIN_C_SOURCE" to pyconfig.h fixes this, but then there's the same "file is not of required architecture" failure seen in later versions. * 2.4.6 behaves the same as 2.5.4 apart from not needing the _DARWIN_C_SOURCE addition. * None of the failures are affected by /opt/local/bin's presence or absence in my PATH. |
|
|
| msg92090 - (view) |
Author: Jesse Noller (jnoller) * |
Date: 2009-08-30 14:54 |
| I'll note I am not doing framework builds, however people have run into problems with non framework builds and macports/old versions of gettext. |
|
|
| msg92092 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-08-30 19:43 |
| The attached patch (configure-in-sl.patch) fixes the build issue on SL, I haven't committed the patch yet because it needs testing on 10.5/10.4. NOTE: the patch touches configure.in without also patching configure. Therefore you need to run 'autoconf' after applying the patch. NOTE2: the patch is for the trunk (2.7), I'll port the patch to the other branches (2.6, 3.2 and 3.1) after testing it on 10.5. |
|
|
| msg92108 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-08-31 14:30 |
| The patch works for me. Thanks. |
|
|
| msg92112 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2009-08-31 17:31 |
| With the patch installed, no regressions were seen running my standard set of OSX installer builds/installs/regtests on 10.4 and 10.5. |
|
|
| msg92153 - (view) |
Author: Mark Miller (mirell) |
Date: 2009-09-02 03:17 |
| This patch allows compiling, and forces everything to be x86_64. However, Python 2.6.2 still dies when attempting to install: cd Mac && make installmacsubtree DESTDIR="" DYLD_FRAMEWORK_PATH=/tmp/Python-2.6.2: ../python.exe ./scripts/cachersrc.py -v /tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/pyth on2.6/plat-mac /tmp/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tool s Traceback (most recent call last): File "./scripts/cachersrc.py", line 44, in main() File "./scripts/cachersrc.py", line 41, in main os.path.walk(dir, handler, (verbose, force)) File "../Lib/posixpath.py", line 224, in walk func(arg, top, names) File "./scripts/cachersrc.py", line 23, in handler macresource.open_pathname(os.path.join(dirname, fn), verbose=verbose) File "/private/tmp/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, in open_pathname refno = Res.FSpOpenResFile(pathname, 1) AttributeError: 'module' object has no attribute 'FSpOpenResFile' make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 This is both with MacPorts, and without MacPorts, in the path, just for those who were wary that this was solely a MacPorts issue. The reason it is dying is because a large number of the calls in Carbon are completely non-existant in 64-bit userspace. An example would be FSpOpenResFile as seen above. Apple issued a notice stating that many of these calls would not exist in Carbon 64-bit (http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/ Carbon64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40 004381-CH1-SW1). What Apple apparently did for their shipped version of Python in Snow Leopard was a hack to combine 32-bit parts of Python for Carbon 32-bit support, and 64-bits. (http://www.opensource.apple.com/source/python/python-44/) The only way I see currently to compile Python 2.6.2 natively on Mac OS 10.6 (On a *64-Bit Capable* machine, this is critical) is to add the EXTRA_CFLAG "-m32" and patch Makefile.in, for two sections which completely ignore/don't include EXTRA_CFLAGS or PY_CFLAGS, or any CFLAGS. This pretty much limits you to a 32-bit version of Python. Because even doing "--host=i686-apple-darwin10 --target=i686-apple- darwin10 --with-universal-archs=32-bit", since the default gcc target on a 64-bit capable machine is x86_64, it still produces x86_64 code in some areas. By doing this, I was able to get Python 2.6.2 to compile *and* install. I'll submit a patch shortly, but the main issue is of course that plat_mac contains many 32-bit only references to the Carbon API. The true fix is to fix that area. But in the interim, you'll have to compile Python as 32-bit. Also, the configure.in patch won't suffice for now, since you *can't* build a 64-bit version of Python on MacOSX from what I've seen, and also as reported by several other users on MacPorts. |
|
|
| msg92211 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-09-03 14:28 |
| My current plan is to fix this issue, and the issue of 64-bit universal builds on SL in the weekend. BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no maintained beyond critical security patches. |
|
|
| msg92213 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2009-09-03 18:27 |
| On Thu, Sep 3, 2009 at 07:28, Ronald Oussoren<report@bugs.python.org> wrote: > > Ronald Oussoren <ronaldoussoren@mac.com> added the comment: > > My current plan is to fix this issue, and the issue of 64-bit universal > builds on SL in the weekend. > > BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no > maintained beyond critical security patches. That's correct. |
|
|
| msg92301 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-09-06 11:11 |
| Fixed in r74672 (trunk), r74681 (2.6), r74682 (3.x) and r74683 (3.1) With the default configure flags you'll end up with a 64-bit build of Python on Snow Leopard, including a 64-bit copy of IDLE. |
|
|
| msg92308 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-09-06 12:38 |
| I tried release26-maint just now (r74683) and it errored out during make install. New log attached. |
|
|
| msg92310 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-09-06 12:41 |
| Could you retry the build after cleaning the target directory? I've seem simular failures in the past and haven't been able to find the root cause of that problem. |
|
|
| msg92311 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-09-06 12:51 |
| Tried again after ensuring that ~/test was completely empty; no difference. |
|
|
| msg92313 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-09-06 13:05 |
| Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather than 'instance'? |
|
|
| msg92314 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-09-06 13:06 |
| Looks like there's a spurious comma in line 110 of lib/plat- mac/macresource.py in the release26-maint branch: if instance(arg, AttributeError), or arg[0] in (-37, -39): |
|
|
| msg92315 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2009-09-06 13:08 |
| You're right. I've fixed this in r74686. |
|
|
| msg92318 - (view) |
Author: Joshua Root (jmr) * |
Date: 2009-09-06 13:28 |
| It works now. Thanks! |
|
|
| msg92344 - (view) |
Author: Bryan Blackburn (blb) |
Date: 2009-09-07 05:56 |
| The patch has one issue in the added AC_TRY_RUN ( http://svn.python.org/view/python/trunk/configure.in? annotate=74672&pathrev=74672#l1542 ): it doesn't like the two [[...]] and main() needs a closing brace, }. Otherwise, it fails on 10.5.8 (Xcode 3.1.3, Intel) to properly detect 32bit vs 64bit (and if you look at config.log you should see complaints from around line 7065). Attaching a patch which fixes it here. |
|
|