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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
