[Pythonmac-SIG] building extension problems on OS X python 2.5.1

[James Boyle]

Thanks for the help.

Using your advice I augmented the Extension definitions in the  
setup.py of  pynetcdf and it worked OK.
BUT when I tried to modify a more complex installation  
(cdat_lite-4.1.2-0.2.2).  I got the same problem as before.
cdat-lite has a tree 3 layers deep and 8 setup.py files. I modified  
every setup.py file but the result was the same as before - both ppc  
and i386? I tried several times  from scratch but it did not work as  
it did for pynetcdf.

Is there any other place that I need to modify with more complex  
situations ?

Perhaps, I need to set something else at the highest level - do  
things get overridden as the build propagates down ?

--Jim

On May 4, 2007, at 10:49 AM, Ronald Oussoren wrote:

>
> On 4 May, 2007, at 18:11, James Boyle wrote:
>
>> INTEL Mac  OS X 10.4.9  Macpython 2.5.1
>>
>> I am having trouble building extensions onto my MacPython 2.5.1.
>> The error for pynetcdf 0.7 is given below but I have had the same
>> error on two other packages.
>>
>> It appears that the builds attempt to make a universal binary by
>> default  and attempt to link to a library that I have built as i386
>> only.
>> The extent of my ignorance is that I would not even know how to build
>> a universal library if I wanted to.
>> These libraries HDF5 and netCDF4 have fairly complex build scripts.
>>
>> I would like to be able to turn off the mechanism that is forcing a
>> universal build. The PPC part is a waste of space for me.
>>
>> Of course, my interpretation of the error might be completely off  
>> base.
>>
>> Appreciate any insight.
>
> The easiest way to fix your problem is by patching setup.py and  
> adding the following two arguments to all Extension definitions:
> 	extra_link_args=['-arch', 'i386'], extra_compile_args=['-arch',  
> 'i386'],
>
> This will tell distutils that you really want a i386 only extension  
> instead of a universal one.
>
> As Christofer mentions as well the best solution in the long run is  
> teaching the libraries you're using to build as universal binaries.  
> I have no idea how hard that would be.
>
> Ronald
>