Re: GCC cross-compilation
Hamish Moffatt wrote:
> On Jun 22, Galen Hazelwood wrote
> > Hamish Moffatt wrote:
> > Nope. What happens is most (single-cpu) developers upload the source
> > and binaries for one architecture. Then helpful and nice developers who
> > own other machines upload binaries for their cpu, built from the source.
> I see. Well, it would seem simpler to cross-compile.
Simpler...but much, much more dangerous. I just sent mail to
debian-devel explaining why I don't trust cross-compilers. If you don't
get debian-devel, the summary is that you (a) can't test the binaries
you produce and (b) cross-compilers can be unstable. Just ask anybody
who ever tried to build alpha binaries on a 32-bit system. :(
> I was thinking that the architecture independent parts of gcc
> could be placed in one package, and the architecture-specific
> parts in another. In my compilation of the cross-compiler,
> I just got a new cc1, etc, under /usr/lib/gcc-lib, and
> some other files. I was thinking that even the i386 files
> could be separated from the actually /usr/bin/gcc binary,
> because the gcc binary doesn't seem to know what
> targets it has by anything except what it can find in
> /usr/lib/gcc-lib; my cross-compile didn't give me a new gcc.
There are no "architecture independent" parts of gcc. The defaults in
such things as /usr/bin/gcc are conditioned by the architecture.
/usr/bin/gcc *does* know what targets it has--it has exactly one, the
one you configured it for. You can get it to use others by command line
flags, but it's just as easy to produce binaries like
"/usr/bin/cpu-os-gcc" which do the job for you. This means that cross
compilers can be installed and used even if you don't have the native
gcc for your system!
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .