Steffen Wendzel wrote: > I run the same Linux version + same Distribution version on > different systems with different x86 based processors: i486 > and better. > > I want to create binarys on this systems that I can use on > all boxes. So i tried to compile my gcc on my i686 machine > using > > ./configure --target=i486 > > what didn't work because of compiling problems. the i486 > stuff wasn't supported. --target is not what you want here. For one thing, --target only applies when building compilers (or in general, code that creates code), not regular libraries. --host is the usual way of specifying a cross compile for libraries. And the format that is expected by these switches is a host triplet, in the form of "cpu-company-os" or "cpu-company-kernel-os", such as "i686-pc-linux-gnu". See <http://www.gnu.org/software/autoconf/manual/html_node/System-Type.html#System-Type>. But you do not want any of that as you are not cross compiling. You simply need to pass the proper -march to the compiler. You do this with CFLAGS (or CXXFLAGS for C++ code, etc.) See <http://www.gnu.org/software/autoconf/manual/html_node/Preset-Output-Variables.html#index-CFLAGS-72> and <http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/i386-and-x86_002d64-Options.html#index-march-1009>. ./configure CFLAGS="-g -O2 -march=i486" Note that if you happen to be using a configure script generated by an ancient version of autoconf (2.13) then you have to do this instead through the environment directly, e.g. CFLAGS="-g -O2 -march=i486" ./configure But these days configure scripts generated by autoconf 2.13 are becoming more and more rare, so the first form is the preferred way. Note also that this only takes care of specifying to the compiler and assembler which instruction set and type of optimizations it can use. It does nothing at all to address the problem of different library ABIs. For example, if your build system is relatively up to date it probably uses libstdc++.so.6 (which corresponds to gcc versions 3.4 and higher.) If you build a C++ app on such a system and then copy the binary to an older system that still uses libstdc++.so.5 then the binary will fail in all kinds of ways. This applies to any library that the application links against, not just libstdc++. This can cause all sorts of headaches if the machine used to compile is of a significantly newer vintage than the machine the binary will run on. Brian
