> ----- Original Message ----- > From: "Bob Ippolito" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 > Date: Mon, 27 Mar 2006 17:44:13 -0800 > > > > On Mar 27, 2006, at 5:10 PM, [EMAIL PROTECTED] wrote: > > >> From: Christopher Barker <[EMAIL PROTECTED]> > >> To: pythonmac-sig@python.org > >> Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems > >> Date: Mon, 27 Mar 2006 09:50:33 -0800 > > > >> Ronald Oussoren wrote: > > > >>> I'd prefer to have 1 installer for python on OSX, that makes > >>> support a lot easier. > > > >> And we would like to by able to use Py2App to build apps that will > >> run under both 10.3.9 and 10.4.* > > That will work as long as the apps don't include anything that > strongly links to 10.4 specific features (e.g. xattr). We've taken > steps to make sure that the right thing happens with Python > itself, but the onus is on third party extensions to also do the > right thing when relevant. For most libraries, there shouldn't be > an issue. > > > But shouldn't we be able to build -ppc, -i386, and even -ppc64 > > with gcc 4.0 and then use 'lipo' to paste them to together and > > let the loader sort them out at run-time? Does the loader on > > 10.3 know enough to pick '-arch ppc' even with other in there or > > am I assuming too much? I'd test it myself, but my G5 1.8 Dual > > has died and my Quad hasn't arrived yet since I am out of town > > for the week ;-(. > > ppc64 is definitely not going to work. You'd need a vanilla unix > build with no Mac specific stuff to do ppc64, because it only > really can talk to libSystem.
I understand--just making a point that the kernel checks the header of the binary to determine how to have it loaded and by which dynamic linker. May be I am stating the obvious, but that, and not combining then with 'lipo' is my assesment of the incorrect configuration of the numpy build 'recipe' > I don't know what you're talking about with regard to "loader". If > you're asking whether 10.3 can run universal binaries, then sure > -- Mac OS X has always had support for fat mach-o files, it's just > the toolchain that's changed such that you can reasonably make > them now. Well I sacrificed recision for brevity. So...I meant the appropriate dynamic linker for the binary as I mentioned above--I was just trying to be terse. Correct me if I am wrong, but still glossing over some details and simplifying, the kernel checks the header of the binary to determine which dynamic linker to use to load the binary's segments. Then they are loaded/overlayed into the process space according to their type by the appropriate linker/segment loader/thing. 'dylibs' are loaded with the timing of the loading depending upon the binding choice, pre-binding being no longer possible in 10.4 and just-in-time being the recommendation now as I recall. So it's just some drudgery to compile for both formats, use 'lipo' to combine them and we have a universal app. Right? Not trying trivialize the work involved--just stating that I think the tools are there and its possible. Daniel > -bob > _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
