I actually meant "weighted majority" of CPUs -- I recognize that not all CPUs can use compatible instruction sets. However, a majority of users are using CPUs that have a common instruction set. I was under the impression that multiple instruction sets are generally supported on each CPU, hence "SSE", "SSE2", "3DNOW", etc. Given that I've seen large lists like that on CPU spec pages/boxes before, I suspect it's the case...
MMX, SSE, 3DNow!, etc are not instruction sets in their own right, but rather extensions of the standard IA-32 instruction set (this is the common instruction set for x86-32 CPUs). Any code which is compiled to use these extensions will
not work on any CPU with an instruction set that doesn't include these extensions. As I understand, it is possible (in assembly) to write two versions of a function (one using the extended instructions and one using the just the standard instruction set) and have the program select which version to use by querying the CPU at runtime, but that's far beyond my level of expertise. Note that this is only possible because these extended instruction sets simply add new instructions without replacing or changing the standard instructions.
Either way, I removed the -march option and it seems to work. The documentation suggests that gcc will decide for me what to compile, which is not march=native. Maybe I still have no idea what I'm talking about, but I'm going with what works. So far the python2.6-i386 works after the change. Please try the others and let me know.
Are you sure it works, though? On
all IA-32 systems? Unless you're absolutely positive the default is safe,
-march=i386 is the only way to be sure. Compiling for any other architecture is very likely to result in a binary that is guaranteed to crash on certain systems.
No, I'm not sure it works on
all systems. But I never had a complaint when using march=native, which should be the least-compitible compilation option. The fact that the gcc documentation says that leaving out the -march= option will pick some default of the year is probably exactly what I want. I think it picks i386 for 32-bit systems and k8 for 64-bit? I'm not totally sure. But it's better than what I had before without having to fill an evening learning about architectures and compilers.
I will take your advice and look into what I should be using. But as I said, the documentation suggests that not specifying the option usually causes it to pick a versatile one, and likely to be appropriate for the popular CPUs of the time that the gcc version was released.
Are you recommending i386 for
all systems, or just the 32-bit systems?
