[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-11 Thread Ned Deily
Changes by Ned Deily : -- nosy: -ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-11 Thread Ned Deily
Ned Deily 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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-11 Thread Ronald Oussoren
Changes by Ronald Oussoren : -- nosy: -ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-10 Thread Martin v . Löwis
Changes by Martin v. Löwis : -- nosy: -loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-10 Thread Ronald Oussoren
Ronald Oussoren 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 __

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-10 Thread Michael Wise
Michael Wise 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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-10 Thread Ned Deily
Ned Deily 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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-10 Thread Michael Wise
Michael Wise 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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-08 Thread Ronald Oussoren
Ronald Oussoren 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,

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2009-10-08 Thread Michael Wise
Michael Wise 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: g

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-12-28 Thread Ronald Oussoren
Ronald Oussoren 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

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Martin v. Löwis
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 w

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
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. Th

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Martin v. Löwis
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. O

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
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 univer

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Martin v. Löwis
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 thes

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
Changes by Ronald Oussoren <[EMAIL PROTECTED]>: -- keywords: +needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
Changes by Ronald Oussoren <[EMAIL PROTECTED]>: -- priority: -> critical ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
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]>

[issue4064] distutils.util.get_platform() is wrong for universal builds on macosx

2008-10-07 Thread Ronald Oussoren
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 d