[issue6802] build fails on Snow Leopard
Mark Miller m...@mirell.org added the comment: 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. -- nosy: +mirell ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
Mark Miller m...@mirell.org added the comment: Not entirely. I applied what you had for the autoconf section to my configure, since I do not have autoconf installed in my environment. Specifically, this part of configure is what's messing with the build: if test x$TARGET = xMIPS; then MIPS_TRUE= MIPS_FALSE='#' else MIPS_TRUE='#' MIPS_FALSE= fi Since the target is being renamed to MIPS_LINUX or MIPS_IRIX, this test assumes the target is not MIPS. The patch you have gets past the build break, but doesn't actually compile what I believe is a working libffi for MIPS. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762561] unable to serialize Infinity or NaN on ARM using marshal
Mark Miller m...@mirell.org added the comment: This still occurs in the latest SVN checkout, and is preventing Python from building on ARMV4L and ARMV5L OABI, dying during the test_float.py compilation. The patch appears to solve this problem, however I have not run a full suite of tests to ensure it doesn't have any regression issues. Since this has been broken since 2007, could this be looked at in getting merged? -- nosy: +mirell type: - compile error versions: +Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1762561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762561] unable to serialize Infinity or NaN on ARM using marshal
Mark Miller m...@mirell.org added the comment: The following is where it fails un-patched: Compiling /usr/local/lib/python2.6/test/test_float.py ... Traceback (most recent call last): File /usr/local/lib/python2.6/compileall.py, line 156, in module exit_status = int(not main()) File /usr/local/lib/python2.6/compileall.py, line 146, in main force, rx, quiet): File /usr/local/lib/python2.6/compileall.py, line 83, in compile_dir if not compile_dir(fullname, maxlevels - 1, dfile, force, rx, quiet): File /usr/local/lib/python2.6/compileall.py, line 65, in compile_dir ok = py_compile.compile(fullname, None, dfile, True) File /usr/local/lib/python2.6/py_compile.py, line 138, in compile marshal.dump(codeobject, fc) ValueError: unmarshallable object make: *** [libinstall] Error 1 This is both on armv4l and armv5l OABI. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1762561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762561] unable to serialize Infinity or NaN on ARM using marshal
Mark Miller m...@mirell.org added the comment: I am in a position to test as much as needed. I am attempting to get Gentoo's ARM/MIPS/Embedded distribution up to date on Python, and noticed this build break. (Typically most embedded architectures are several releases behind.) I'll try this new patch right now. As for it only being with OABI, that's correct, and yes, it will decrease in numbers as time goes on, since most higher-end embedded processors are EABI currently. The concerns are valid, I understand, but since it seems to be a relatively minor change, I wouldn't see the real harm in this case, especially since otherwise Python seems to work just fine under ARM OABI. But yes, if you're looking at it from a perspective as if it will still be used prevalently in 3-5 years, it's use will be minor, with OABI especially, but that's always the trend in embedded architectures. Regardless, I'm very grateful for both Aurelian Jarno and Mark Dickinson for coming up with a patch that works to get me past my build breaks. -- versions: +Python 2.5 -Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1762561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
Mark Miller m...@mirell.org added the comment: Would it be possible to get some feedback as to whether this is a candidate for Python 2.6 on this patch? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762561] unable to serialize Infinity or NaN on ARM using marshal
Mark Miller m...@mirell.org added the comment: The new patch works correctly, by the way, on ARMv4L and ARMv5L OABI boards. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1762561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
Mark Miller m...@mirell.org added the comment: It's actually due to the merge of the libffi3 branch back in March, which removed the logic for configure to deal with MIPS in fficonfig.py.in. I've attached a patch which allows the build to work correctly on the QEMU instance of the MIPSEL machine I have. -- keywords: +patch nosy: +mirell Added file: http://bugs.python.org/file12617/mips-ffi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)
Mark Miller m...@mirell.org added the comment: Adding this as affecting the 2.6 branch as well, since I initially tested on a 2.6.1 tarball with this problem. -- versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
