[Pythonmac-SIG] building universal binaries

[Bob Ippolito]

On Jan 26, 2006, at 10:39 PM, Kevin Ollivier wrote:

> On Jan 26, 2006, at 7:02 PM, Bob Ippolito wrote:
>
> [snip]
>
>>> IMHO, what would be cool is to allow the user to pass the SDK in as
>>> some sort of configure flag or maybe a shell variable, something  
>>> like:
>>>
>>> ./configure <flags> MACOSX_SDK=/my/path/to/SDK
>>>
>>> This, along with the addition of the -arch i386 -arch ppc flags  
>>> would
>>> be enough to enable someone to write a script to create a Panther-
>>> compatible Universal build. Which I'm pretty sure someone will do
>>> sooner or later. :-)
>>
>> No, it wouldn't actually.  The 10.3 SDK is ppc only, and a Panther- 
>> compatible build (well, something compatible with 10.3.8 and  
>> below) must use GCC 3.3, but an x86 compatible build must use GCC 4.
>>
>> In other words, something Panther compatible needs to use  
>> different compilers with totally different options for x86 and  
>> PPC.  It's not going to be easy, distutils doesn't come anywhere  
>> near close to supporting anything like that and neither does  
>> autoconf.
>
> Sorry, I wasn't really thinking about extensions. By Panther I did  
> mean building against the 10.3.9 SDK, which would give the desired  
> results for the Python binary itself, but as you said extending  
> that to correctly build extensions that did the same thing would be  
> a royal PITA.

You still need to build against two different SDKs, which can't be  
done with just compiler flags.  You have to do two separate compiles,  
and then lipo it together.  At that point you might as well use  
different compilers and target older versions of OS X.  The other  
thing is that Python's build probably detects a few things at  
runtime, and at runtime it's seeing 10.4, so it might not actually  
work on the target version of OS X.

Ideally all that stuff would be pushed to runtime checks, so that it  
could choose a different code path based upon which APIs are  
available... but first you have to isolate the instances where that  
happens.

>> I think the only approach that doesn't require hacking a  
>> significant amount of Python's build process and distutils is to  
>> have two Python installations, one x86 only and one PPC only.  For  
>> distribution, you would cook up some way to lipo it all together.
>
> I can see how the issues with the strategy I outlined would be  
> significant, but I don't see how Universal support on Tiger would  
> be similarly difficult. Apple's Python 2.3.5 already is Universal,  
> and I'm unaware of any issues with it (except that it doesn't build  
> Universal extensions ;). The changes they made to the build process  
> seemed to be fairly minimal.

Yeah, a 10.4+ universal build wouldn't be too big of a deal because  
you can do that with one invocation of GCC and one set of flags.

> As far as distutils/working with extensions, I admit I'm not very  
> familiar with that. I did notice when compiling wxPython though  
> that there weren't any distutils flags passed to gcc that would  
> conflict with the building of Universal binaries. The main question  
> in my mind would be whether or not the built Universal extension  
> libraries could be loaded by Python's dynamic library loader. If  
> they can be loaded, and we could add the flags to distutils'  
> default compiler/linker flags, what other major issues would need  
> to be overcome?

Some extensions aren't going to build cleanly universal, and most  
users probably aren't going to have all the SDKs installed so if it  
shipped with universal flags then it wouldn't be able to build  
extensions.

-bob