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!
--Galen
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: