natasha@xxxxxxxx wrote:
We plan to use x86_64 linux machine to build binary code that can
eventually run on i386 machine. I know it's possible with -m32.
On 'i386 machine'? Not even those "developing countries" will accept
anything
less that "400 MHz with P-II", or it was still better, "600 MHz with
P-III" :-) Maybe
you meaned to say 'i686 machine' (Pentium Pro, P-II, P-III,...)?
Anyway the '-m32' may not be enough if it produces code for 'AthlonXP'
in the
AMD64 family. For what CPU it produces code is quite unclear (at least
for me).
In your case I would try to find out this! There are those '-march=',
'mcpu=' etc.
options for the x86 family too...
I wonder if there is an easy way to configure/build GCC so that it would
produce 32-bit binaries by default?
Maybe you don't mean "binaries" like "objects"? But "executables", the
GCC & as
produced binaries linked with some target's C, C++ etc. libraries....
The reason I want this is because we build many products, and it may be
more difficult to implant -m32 option in every build system.
Producing executables for "other" systems usually requires one or more
cross-toolchains
for them... Or using an older-than or the same "version" system..
For instance if producing
code for SuSE Linux 9.1, the produced code is expected to work on the
10.x systems too.
But not vice versa! This is usually called "backwards compatability".
That executables made
for SuSEs would run in Fedoras/RedHats may be quite true but I would
make some tests before
being sure...
So you should also think what could be that "least common nominator" in
the target group,
what could be the "oldest" system in them what comes to its glibc
version etc. And then
make a crosstoolchain for that system if believing in "backwards
compatability". But it can
be fully possible that you could need several crosstoolchains for
different brands of 32-bit
Linuces...
Producing a crosstoolchain is a piece of cake for anyone with the right
know-how, but for
newbies that "cross" could be translated to "crescent" or "half-moon",
like from "Red Cross"
to "Red Crescent", meaning that it takes "half-moon/month" to build one
:-) The new world
after the "native" world can look being totally different.... And all
the weird advices in the net
only make the situation still harder.
Generally the problem is that one should be familiar with the "GCC
components", which then
really aren't "parts of GCC" at all. Like GNU binutils and GNU C library
(glibc), which Linux
uses as these components for binutils and C library. The "GCC" alone
cannot do much.... OK,
in a crosstoolchain the binutils and the GCC must be built from their
sources to produce/handle
stuff for the target in question ('i686-linux-gnu' in your case most
probably being the choice).
But all the target libraries, glibc, termcap, ncurses, Gnome. KDE etc.
libraries should be taken
'as is' from the target (the "least common nominator" in the target
group). Quite many
instructions in the net may tell that also these should be built
oneself, but just don't believe this
"bullshitism".... In any case using a prebuilt target C library during
a GCC build is easy as a pie
if compared to those "from absolute scratch" political ideas in the net
instructions. Of course
it is sad that the old Finnish Karelian wisdom, "Those who know how to
do something will do
that, but those who don't know how to do that can only give advices for
others how to do that!"
From pure ignorancy all kind of weird ideas will arise and those which
tell that one should always
"reinvent the wheel" are ones which belong to this "weird" group...
Maybe there are also sane instructions for producing crosstoolchains but
when one just does these,
one doesn't need advices and generally it would need a horrible amount
of time and energy to
convert that "chaff in the wind"-type people from their weird political
ideas about "starting everything
from absolute scratch" being the way to a "better world" (as a Finn I
know what happened behind our
eastern border in 1920's and 1930's in those "from scratch" experiments,
the goal being maybe nice
but the results being considered horrible if seen from a "social
democracy", where "bettering the
existing step-by-step" was the rule). Maybe it sounds weird to mix
political ideas to cross-compiling
but it is quite obvious if being educated as a "control/system
engineer", learned to see "analogies"
between pipes and resistors, containers and capacitors, stores being
integrators etc. "Analysts of the
chaos" I would say... Surely you will find out the Dan Kegel's
"crosstool", originally aimed for making
a crosstoolchain from absolute scratch for those who will then build
their Linux too from absolute
scratch. But then having changed into a "universal fit-for-all-diseases
wonder-liquid"...
