Finn Thain dixit: >> There are code generation differences, disabled optimisation passes, etc. > >I'm not aware of code generation differences. Can you be more specific?
Sadly, not by a number of quick greps. It’s something I remember from some time ago, and I *think* I’ve seen cases in gcc’s source where calls were explicitly not done for cross compilers, but cannot find them right now. If this has changed in the meantime, even better, but recently, people discussing pcc vs. gcc still said that pcc uses the exact same code paths for native vs. cross (actually, that pcc doesn’t care whether it’s a native or cross compiler), whereas gcc makes big noise about it. If this has indeed changed in gcc, I’d like pointers ☺ and will apologise. >No, it is like saying that MS Outlook works for most people (or they >simply wouldn't pay for it). Linux cross-compilers are commercial >products. Hrm. Yes. But that still doesn’t make it good (per se), right? ;-) >You are perhaps too young to remember EGCS, but I do. If it weren't for I used gcc 2.7.2.3 on Linux 2.0 (before knowing about the LFS book, I did something similar – before having internet access at home, actually… I remember downloading a diff between 2.0.36 and .38 and putting it on floppies, as well as other things missing from the SuSE 6.1 and Debian slink source CDs which I wanted, and carrying these home from school), heard about pgcc, seen egcs, and remember when they said egcs is to become the new gcc. >Cygnus and later CodeSourcery, the GNU toolchain would certainly not be >what it is today. I agree. Others, too (think Ada; wasn’t g++ also added by a third party and only because of the GPL?). From what little I played with gpc (which is part of MirBSD’s base gcc too), I think its develop- ment is also often company-driven. >All native compilers, cross compilers, emulators and silicon have bugs. Aye! >that all architectures started life from emulators and cross-compilers. They know that, just they want to stop using them after the architecture has been bootstrapped. I *think* they have been bitten by bugs. Another of their arguments is that only by compiling natively the hardware is exercised so that the (silicon) bugs show up, which can then be worked around. (Maybe it’s also a we-are-better-than-you attitude… with those guys you never know. They did burn a donated T-Shirt after all *and* put the video of that into the net…) >Probably they are also unaware of Plan 9. I think these two have a love-hate relationship with each other :) >This does not argue against emulation, it is argues against ONLY emulating >(the context was the lack of a working physical buildd). OK, sorry then. I propose that I now (see below) get cowbuilder going with the packages I have, then recompile everything needed for a buildd, make a sort of bootstrap apt repo out of that, and then we can start running a real buildd on real hardware again. I will make use of Ingo’s boxen during the process, and upload things like gcc, binutils, etc. to d-p.o after they pass their respective testsuites on real hardware, if possible. (I want to upload packages needing a TLS capable kernel only after we have one of them in the archive _anyway_, so the delay isn’t bad, be- sides I’ll send appropriate sources.list lines here once it is set up.) Is that agreeable with you? Well, that said: -rw-r--r-- 1 root root 10514 Oct 23 12:15 eglibc_2.11.2-6+m68k.2_m68k.changes I’m putting this up here: http://www.freewrt.org/~tg/aradebs/dists/tlsdirty/unreleased/Pkgs/eglibc/ @all: Remember these packages are built in an environment with Finn’s eglibc sysroot extracted, i.e. more than just unclean ☺ but they will be used in compiling gcc-4.4 and eglibc that can in the end be uploaded (although I’ll likely recompile (binNMU) everything, just to make sure they are clean). bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1010231516530.21...@herc.mirbsd.org
