You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
cd Mac && make installmacsubtree fails on Mac OS X < 10.5 because of r63955 #47643
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2008-07-18.05:45:38.664>created_at=<Date2008-07-17.17:02:47.336>labels= ['build']
title='`cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955'updated_at=<Date2008-07-18.06:25:08.035>user='https://bugs.python.org/trentm'
I don't fully understand why the "arch -ppc -i386" is necessary for
"$(BUILDPYTHON)".
I'm not sure what the easiest solution to this would be... or if
supporting "make frameworkinstallframework" (which eventually calls this
target) on Mac OS X <10.5 is considered important enough.
Perhaps a new
RUNARCH=@RunArch@
could be added to Mac/Makefile.in with the associated configure support
to have that be blank unless --with-universal-archs=all was specified?
Alternative potential solution: use the ARCHPREFERENCE environment
variable as described in the Mac OS X 10.5 arch man page. Ronald, if you
could test if that works for you on 10.5, then presumably setting that
environment var would be safely ignored on Mac OS X <10.5. Thoughts?
Activity
trentm commentedon Jul 17, 2008
http://svn.python.org/view?rev=63955&view=rev
"MacOS X: Enable 4-way universal builds ..."
This revision made the following change to Mac/Makefile.in:
http://svn.python.org/view/python/trunk/Mac/Makefile.in?rev=63955&view=diff&r1=63955&r2=63954&p1=python/trunk/Mac/Makefile.in&p2=/python/trunk/Mac/Makefile.in
The last hunk (part of the "installmacsubtree" target) and a bit of the
preceding hunk uses
archwith arguments:---------------------------------
That form of calling
archis only supported on Mac OS X 10.5(Leopard), I believe.
----------------------------------
$ sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 $ man arch | catARCH(1) BSD General Commands Manual
ARCH(1)
NAME
arch -- print architecture type
SYNOPSIS
arch
DESCRIPTION
The arch command displays the machine's architecture type.
SEE ALSO
machine(1)
Mac OS August 20, 1997
Mac OS
----------------------------------
Here is the current man page for arch (I had to look to try to see what
Ronald was trying to do with the Makefile change) :)
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/arch.1.html
I don't fully understand why the "arch -ppc -i386" is necessary for
"$(BUILDPYTHON)".
I'm not sure what the easiest solution to this would be... or if
supporting "make frameworkinstallframework" (which eventually calls this
target) on Mac OS X <10.5 is considered important enough.
Perhaps a new
RUNARCH=@RunArch@
could be added to Mac/Makefile.in with the associated configure support
to have that be blank unless
--with-universal-archs=allwas specified?trentm commentedon Jul 17, 2008
Similar change in Mac/IDLE/Makefile.in:
-----------------------------
trentm commentedon Jul 17, 2008
Alternative potential solution: use the ARCHPREFERENCE environment
variable as described in the Mac OS X 10.5 arch man page. Ronald, if you
could test if that works for you on 10.5, then presumably setting that
environment var would be safely ignored on Mac OS X <10.5. Thoughts?
ronaldoussoren commentedon Jul 18, 2008
This patch is wrong, it drops the call to 'arch' entirely even when the
call is needed.
The suggestion for "ARCHPREFERENCE" won't work though, "arch" doesn't take
arguments at all on 10.4.
BTW. This is a duplicate of bpo-3381, which includes a patch for fixing
the issue.
ronaldoussoren commentedon Jul 18, 2008
The current trunk should be correct, there are no explicit calls to the
arch command left, all go through the configure replacement magic.
To test if everything is correct now someone should test the following
scenarios:
Build --enable-framework --enable-universalsdk on 10.4
Build --enable-framework --enable-universalsdk on 10.5
Build --enable-framework --enable-universalsdk --with-universal-
archs=all on 10.5
I cannot test the first one, and will test the last one (which is the
one I'm most interested in).
ronaldoussoren commentedon Jul 18, 2008
BTW. There is a "--with-framework-name" argument to configure that makes
it possible to have several indepenend framework installations
trentm commentedon Jul 18, 2008
--------------------
$ svn info Path: . URL: svn+ssh://pythondev@svn.python.org/python/trunk/Mac Repository Root: svn+ssh://pythondev@svn.python.org Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 65091 Node Kind: directory Schedule: normal Last Changed Author: ronald.oussoren Last Changed Rev: 65091 Last Changed Date: 2008-07-17 22:48:03 -0700 (Thu, 17 Jul 2008) Properties Last Updated: 2008-07-17 22:55:32 -0700 (Thu, 17 Jul 2008)[trentm@mower:
$(RUNSHARED) arch -ppc -i386 $ (BUILDPYTHON)
$(RUNSHARED) arch -ppc -i386 $ (BUILDPYTHON) $(CACHERSRC) -v
$(DESTDIR)$ (MACLIBDEST) $(DESTDIR)$ (MACTOOLSDEST)
/src/python/Mac]/src/python/Mac]$ svn up Makefile.in
At revision 65091.
[trentm@mower:
$ grep "arch -" Makefile.in
$(srcdir)/scripts/BuildApplet.py \
--------------------
Apologies if I am missing something. Your patches for bpo-3381 did
not include a change to Mac/Makefile.in.
Trent