compiling code for different machines

[Brian Dessent]

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