On 24/07/2005, at 4:20 PM, Bob Ippolito wrote: > > I fixed this problem for 2.4.1 (CVS HEAD should be fine too). I > don't really consider 2.3 important enough to spend my time > backporting. If you notice, Apple didn't compile Python 2.3 under > gcc 4 either.
I got a chance to look at the 'fix' and it is still does not seem right to me. I can't see $(LOCALMODLIBS) in the link or am I missing something on this? The main problem, as I see it, is using libtool to build the libraries, which is inherently fragile and is going to keep breaking particularly as Apple introduce more changes for the x86 transition. The documented way is to use the compiler driver gcc. This will automatically call ld, libtool and even lipo repeatedly if necessary to construct fat libraries. It will also automatically include the necessary system libraries, which it seems to me are very likely to change again. Finally the command will work with any compiler/MacOS combination without modification. A few small points. If you are determined to use libtool, it would be good to use the full path. libtool on my machine means /usr/local/ bin/libtool which is gnu libtool. The same would probably happen with Fink. /usr/bin/libtool is guaranteed to be Apple's libtool. Also I notice that -lcc_dynamic is now removed for gcc-4.0, but I don't see why it is there at all. Its purpose is to get rid of unresolved symbols restFP and saveFP. This problem only happens when trying to link objects compiled with an Apple gcc with some compiled with the FSF gcc. Since Apple provide C, C++, Objective-C and Objective-C++, this only arises when linking Fortran code which has been built with the FSF g77. Since there is no Fortran in Python, it can be removed altogether. The fix I suggested is much simpler, more robust and removes the need to test in configure for different OS/compiler versions. Finally, I don't see the point of '-arch_only ppc' as far as I know, the default is to use the host architecture. It seems to me that the option, which is not configured, just guarantees that things will break on x86. Cheers Bill _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
