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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .