This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Create a fat build on darwin
Type: enhancement Stage:
Components: Build Versions:
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: bob.ippolito, ronaldoussoren
Priority: normal Keywords:

Created on 2005-06-10 16:34 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg54570 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2005-06-10 16:34
Apple recently announced that they will switch to intel CPU's for their 
systems. They request that vendors build fat binaries for software. 
IMHO the python build process should be changed to make this 
easily possible.

Areas that (might) need changing:
* autoconf checks for CPU features (endianness, sizes of basic 
types). That won't work with cross-builds. A possible solution: create 
a pycpufeatures.h that hardcodes the information.

* distutils might need to be taught about creating fat binaries.

* It might be necessary to link to a specific SDK, this in turn might 
require changes in the autoconf machinery.

NOTE: I intend to do some work on this in due time.
msg54571 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2005-06-15 01:42
Logged In: YES 
user_id=139309

There's a lot of things to consider here, including but not limited to:

If building universal binaries that maintain compatibility with Mac OS X 
10.3 (two SDK), you'll need to build i386 and ppc architectures 
separately and lipo them together (might as well do ppc64 too).

If building universal binaries that maintain compatibility with Mac OS X 
10.2 (two SDKs, and two compilers!),  you'll need to build with GCC 3.3 
on ppc and GCC 4.0 on i386 with entirely different CFLAGS/LDFLAGS/
MACOSX_DEPLOYMENT_TARGET than the i386 side of things (that's 
scary).

Some modules aren't available for every arch.  For example, psyco isn't 
really useful except on i386.  PyObjC, anything that links to Carbon, etc. 
isn't going to compile on ppc64, etc.  If the ".so" is there (i.e. universal 
binaries for plugins) then the PyImport machinery will see it, try and 
import it, and get a very nasty low-level dyld error.  Either the PyImport 
machinery should inherit code that checks for arch sanity, or there 
should be separate naming conventions (.i386.so) or locations (site-
packages-ppc) for each arch!

Because of the previous consideration, there will have to be ways to tell 
distutils which architectures you want to compile for.. perhaps just 
native by default, but allow (multiple-?)SDK multiple-arch builds if 
requested.
msg54572 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-25 10:58
Logged In: YES 
user_id=580910

The current HEAD fully supports this, closing this item.
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 42072
2005-06-10 16:34:06ronaldoussorencreate