[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: -ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ned Deily n...@acm.org added the comment: 10.3 is a red herring, that is the deployment target and is as expected. If you install the current proper versions of Xcode for your 10.4 or later systems, things will work as designed. Again, this is not the proper forum to discuss build problems. If you still have problems, suggest asking questions in the pythonmac-sig mailing list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Ned Deily n...@acm.org: -- nosy: -ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Michael Wise michael.w...@uwa.edu.au added the comment: Dear Ronald Not that simple. I had, for the first time, installed Python 2.6.3 via the .dmg rather than compiled from scratch, and then numpy, again via the .dmg. I was trying to compile biopython from scratch using disutils when the problem occurred. That was on a G4 PPC Mac laptop. On a different G5 PPC PowerMac, I did the whole job from scratch and all was well. I can confirm that get_platform was not the problem (check it specifically) and I got something to work by modifying the config/Makefile, but then worried about what else that would affect. I removed the .dmg supplied Python and numpy, and installed Python 2.6.3 from scratch, but had problem of the disutils installation of numpy hanging, so I removed that and did the whole job based on the previous installation 2.5.2. Cheers MichaelW Ronald Oussoren wrote: Ronald Oussoren ronaldousso...@mac.com added the comment: Michael: please file a new issue for this, your problem seems to be unrelated to this one. In that issue include information about: 1) The python version you are using 2) The version of MacOSX 3) The version of Xcode (open /Developer/Applications/Xcode.app, check the version in the About dialog) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ned Deily n...@acm.org added the comment: gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ... followed, unsurprisingly, by: gcc-4.0: installation problem, cannot exec 'i686-apple-darwin8-gcc-4.0.0': No such file or directory From at least OS X 10.4 on, Xcode installs both variants of compilers so it is possible to build both Intel and PPC archs on any system. I regularly build complete fat Python installers on a PPC G3 running 10.4. $ uname -p powerpc $ i686-apple-darwin8-gcc-4.0.1 i686-apple-darwin8-gcc-4.0.1: no input files Was this possibly on an older version of OS X, say 10.3? Otherwise, it sounds like that system did not have a complete installation of Xcode somehow. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Michael Wise michael.w...@uwa.edu.au added the comment: Dear Ned Odd you should say that. The system is the latest version of 10.4 (10.4.11), but I did notice that the compiler assumed 10.3. The version of Xcode on this PowerBook G4 is 2.0 (quite old), so perhaps it has OSX 10.3 wired in. I don't think that was the issue, but to eliminate it I'll download Xcode when I'm at work on Monday (better bandwidth) and see if that does a better job. Cheers (and thanks!) Michael Ned Deily wrote: Ned Deily n...@acm.org added the comment: gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ... followed, unsurprisingly, by: gcc-4.0: installation problem, cannot exec 'i686-apple-darwin8-gcc-4.0.0': No such file or directory From at least OS X 10.4 on, Xcode installs both variants of compilers so it is possible to build both Intel and PPC archs on any system. I regularly build complete fat Python installers on a PPC G3 running 10.4. $ uname -p powerpc $ i686-apple-darwin8-gcc-4.0.1 i686-apple-darwin8-gcc-4.0.1: no input files Was this possibly on an older version of OS X, say 10.3? Otherwise, it sounds like that system did not have a complete installation of Xcode somehow. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren ronaldousso...@mac.com added the comment: Michael: Again, please file a new issue for your problem because it is not related to this one. I'm removing myself from the nosy-list for this bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Martin v. Löwis mar...@v.loewis.de: -- nosy: -loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Michael Wise michael.w...@uwa.edu.au added the comment: While the discussion seems to think the matter is closed, I wanted to install numpy 1.30 which requires Python 2.6 and all my machines are PPC (G4 or G5 - nice architectures). gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing ... followed, unsurprisingly, by: gcc-4.0: installation problem, cannot exec 'i686-apple-darwin8-gcc-4.0.0': No such file or directory Work around, please? Cheers MichaelW -- nosy: +mw263 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren ronaldousso...@mac.com added the comment: Michael: please file a new issue for this, your problem seems to be unrelated to this one. In that issue include information about: 1) The python version you are using 2) The version of MacOSX 3) The version of Xcode (open /Developer/Applications/Xcode.app, check the version in the About dialog) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren ronaldousso...@mac.com added the comment: I've committed the patch with some documentation in r67988, with a backport to 2.6.x in r67989. r67990 (not backported) is a minor update of the patch, it adds explicit support code for all three variants that are configurable through the configure script. I don't think it is useful to worry about architectures that are not supported by current releases of MacOSX. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren [EMAIL PROTECTED] added the comment: On 7 Oct, 2008, at 22:13, Martin v. Löwis wrote: Martin v. Löwis [EMAIL PROTECTED] added the comment: Somewhere along the way the calculation of the architecture string got messed up, resulting in the current situation. That is, the current situation is not as designed by the original author of the universal binary support code. Ok, what *is* the desired way of naming architectures on that system? Is that documented somewhere? It is not documented anywhere but in the code, but this is the intended behaviour: * A single architecture build (what you would build on any other unix platform) uses the architecture string of the architecture it was build for (that is, i386, ppc, x86_64 or ppc64) * A 32-bit universal build uses fat as the architecture string, regardless of the architecture of the machine we're running on. As an exception: OS X 10.3.9 machines are treated as if we're on a single architecture build because the compiler on that platform doesn't support building fat binaries. * A 4-way universal build (that is, including all architectures supported by OSX) uses universal as the architecture string. We (Bob Ippolitto and I) had some discussion about the architecture strings when we were working on support for universal binaries and rejected my initial suggestion of using i386,ppc instead of fat because that would be unwieldy. Ronald ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Martin v. Löwis [EMAIL PROTECTED] added the comment: It is not documented anywhere but in the code These also appear in file names of bdist commands, right? So I think it should be documented. We (Bob Ippolitto and I) had some discussion about the architecture strings when we were working on support for universal binaries and rejected my initial suggestion of using i386,ppc instead of fat because that would be unwieldy. OK. I wonder how you will call fat 64-bit binaries (i.e. ppc64 and amd64), but I can live with that semantics as long as it's documented (I actually question that it is documented in the code. If somebody would put -arch Itanium in her CFLAGS, which might be supported in 10.9, it would infer that the architecture is fat). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Ronald Oussoren [EMAIL PROTECTED]: -- priority: - critical ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
New submission from Ronald Oussoren [EMAIL PROTECTED]: When using a universal build of python on macosx distutils.util.get_platform should use fat for the machine architecture, instead of the architecture of the current machine. That's not what's currently happening: $ python26 -c 'from distutils.util import get_platform; print get_platform()' macosx-10.3-ppc $ -- components: Distutils messages: 74432 nosy: ronaldoussoren severity: normal status: open title: distutils.util.get_platform() is wrong for universal builds on macosx versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren [EMAIL PROTECTED] added the comment: The attached patch fixes this issue. -- keywords: +patch Added file: http://bugs.python.org/file11725/issue4064-fix.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Changes by Ronald Oussoren [EMAIL PROTECTED]: -- keywords: +needs review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Martin v. Löwis [EMAIL PROTECTED] added the comment: When using a universal build of python on macosx distutils.util.get_platform should use fat for the machine architecture, instead of the architecture of the current machine. Can you please explain why it should do so? Where do these architecture names come from? -- nosy: +loewis title: distutils.util.get_platform() is wrong for universal builds on macosx - distutils.util.get_platform() iswrong for universal builds on macosx ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Ronald Oussoren [EMAIL PROTECTED] added the comment: The basic idea is that the architecture bit of get_platform() should tell you something about the archicture for which a build is valid. That's why 'i386' or 'ppc' is not very useful for a universal build. The original author of the universal binary support choose 'fat' as the architecture designator for universal builds (fat binaries). Somewhere along the way the calculation of the architecture string got messed up, resulting in the current situation. That is, the current situation is not as designed by the original author of the universal binary support code. Another reason for fixing this is that setuptools uses the platform designator of the current system and a downloaded binary archive to determine if the two are compatible. In the current situation univeral binary distributions built on a PPC system don't work on an i386 system (as far as setuptools is concerned). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx
Martin v. Löwis [EMAIL PROTECTED] added the comment: Somewhere along the way the calculation of the architecture string got messed up, resulting in the current situation. That is, the current situation is not as designed by the original author of the universal binary support code. Ok, what *is* the desired way of naming architectures on that system? Is that documented somewhere? -- title: distutils.util.get_platform() is wrong for universal builds on macosx - distutils.util.get_platform() is wrong for universal builds on macosx ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
