Changes by Ronald Oussoren ronaldousso...@mac.com:
--
nosy: -ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4064
___
___
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.
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
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
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
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.
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
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
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 ...
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
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
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
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
Changes by Ronald Oussoren [EMAIL PROTECTED]:
--
priority: - critical
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4064
___
___
Python-bugs-list
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
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
Changes by Ronald Oussoren [EMAIL PROTECTED]:
--
keywords: +needs review
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4064
___
___
Python-bugs-list
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
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
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,
20 matches
Mail list logo
