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 <module>
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.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:52 | admin | set | github: 51051 |
2009-09-07 05:56:43 | blb | set | files:
+ configure.in.diff
messages:
+ msg92344 |
2009-09-06 13:28:47 | jmr | set | messages:
+ msg92318 |
2009-09-06 13:08:11 | ronaldoussoren | set | messages:
+ msg92315 |
2009-09-06 13:06:09 | mark.dickinson | set | messages:
+ msg92314 |
2009-09-06 13:05:57 | jmr | set | messages:
+ msg92313 |
2009-09-06 12:51:20 | jmr | set | messages:
+ msg92311 |
2009-09-06 12:41:37 | ronaldoussoren | set | messages:
+ msg92310 |
2009-09-06 12:38:30 | jmr | set | files:
+ release26-maint.log
messages:
+ msg92308 |
2009-09-06 11:11:30 | ronaldoussoren | set | status: open -> closed resolution: accepted -> fixed messages:
+ msg92301
stage: resolved |
2009-09-03 18:27:17 | brett.cannon | set | messages:
+ msg92213 |
2009-09-03 14:28:26 | ronaldoussoren | set | messages:
+ msg92211 |
2009-09-03 13:54:35 | fideli | set | nosy:
+ fideli
|
2009-09-02 03:17:07 | mirell | set | nosy:
+ mirell messages:
+ msg92153
|
2009-08-31 19:14:12 | xaoslaad | set | nosy:
+ xaoslaad
|
2009-08-31 17:31:10 | ned.deily | set | messages:
+ msg92112 |
2009-08-31 14:30:56 | mark.dickinson | set | messages:
+ msg92108 |
2009-08-30 19:43:26 | ronaldoussoren | set | files:
+ configure-in-sl.patch resolution: accepted messages:
+ msg92092
keywords:
+ patch |
2009-08-30 18:15:59 | grdnwsl | set | nosy:
+ grdnwsl
|
2009-08-30 17:48:55 | mitchellh | set | nosy:
+ mitchellh
|
2009-08-30 14:54:41 | jnoller | set | messages:
+ msg92090 |
2009-08-30 14:25:56 | jmr | set | messages:
+ msg92088 versions:
+ Python 2.5, Python 2.4, Python 3.0 |
2009-08-30 07:28:14 | ronaldoussoren | set | messages:
+ msg92083 |
2009-08-30 06:48:47 | ned.deily | set | nosy:
+ ned.deily messages:
+ msg92082
|
2009-08-30 02:58:54 | David Whetstone | set | nosy:
+ dmw
|
2009-08-30 02:33:41 | jmr | set | messages:
+ msg92077 |
2009-08-30 02:20:20 | jnoller | set | messages:
+ msg92076 |
2009-08-30 01:45:11 | jnoller | set | nosy:
+ jnoller messages:
+ msg92075
|
2009-08-30 01:41:14 | brett.cannon | set | messages:
+ msg92074 |
2009-08-30 01:10:03 | brett.cannon | set | nosy:
+ brett.cannon
|
2009-08-29 23:23:33 | easel | set | nosy:
+ easel
|
2009-08-29 21:56:09 | eric.smith | set | nosy:
+ eric.smith
|
2009-08-29 21:07:39 | mark.dickinson | set | messages:
+ msg92070 versions:
+ Python 3.1, Python 2.7, Python 3.2 |
2009-08-29 21:01:06 | mark.dickinson | set | nosy:
+ mark.dickinson
|
2009-08-29 20:46:36 | blb | set | nosy:
+ blb
|
2009-08-29 20:30:57 | jmr | create | |