[ python-Feature Requests-1218333 ] Create a fat build on darwin

[SourceForge.net]

Feature Requests item #1218333, was opened at 2005-06-10 12:34
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create a fat build on darwin

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2005-06-14 21:42

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1218333&group_id=5470