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 > _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig