Hi, On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote: > On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote: > > Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we > > must be joking? > > Hey, I haven't seen any activity wrt m68k archive (re)qualificiation.
You haven't been looking good enough, then. > Given m68k's dropped back below the 95% cutoff (and has spent about > 1/3rd of the last 90 days beneath it) and has a number of red squares > still on the release arch qualification page it seems certain at this > point that you won't get a "release arch" exception any time soon. That's being worked on. The backlog started because there were not enough build daemons to keep up with the extra work introduced by the move to GCC4. This has been remedied in the mean time, and we're back to 0 needs-build on a regular basis. Also, the extra CPU power that this new port will bring us is most certainly going to improve our position in that area. The fact that we're not completely caught up yet has everything to with a number of toolchain issues that need work. I'm trying to tackle them one at a time; currently I'm working on #340563 (which was cloned into #345574 for g++-4.0), and on which I intend to look a bit further sometime during next week or so. It doesn't help that I'm not all that familiar with the innards of the gcc and binutils code yet, but then I expect that by doing more work on such bugs and by doing work on the coldfire-support will help me to improve in that area. Your concern is grounded, though, and I'm not entirely confident at this point that we'll be able to make it, either--help in this area is most certainly appreciated. > > Anyway. To cope with the above issues, the m68k port's developers have > > been looking for alternatives for quite a while now. It has been > > suggested that we start employing distcc or similar things so that we > > would be able to use cross-compilers on much faster hardware, but for > > various reasons this is not practical. > > BTW, it's not very encouraging when you say "Yes, we'll definitely try > this and see how it works!" then, six months later, fail to have ever > bothered, and can only handwave it away as being "impractical". No, I did try it. I did, however, neglect to bring out the results in the open. Mea culpa. Here goes: When I first tried to create this setup, about a month after DebConf5 (and about around the time when I announced this), it turned out that it was plain impossible to build a cross-compiler with the GCC4 code; not with toolchain-source (because that had not been updated yet to GCC4, so would be useless for this purpose) but also not with the upstream source and the scripts from kegel.com: Some internals of the GCC4 code expected that the compiler and the binutils would be called 'm68k-linux-foo', whereas other bits expected 'm68k-linux-gnu-foo'. Obviously this could be fixed by someone familiar with the gcc/binutils build system, but that's besides the point; the point is that rolling our own, very special, setup might introduce extra weaknesses (I had warned in Helsinki about the possibility that a cross-compiler might not produce the very exact same object code that a native build would, but had not considered the possibility that there might be bugs in the build system which would only occur when trying to build cross-compilers). This would complicate such a setup further. Additionally, Ingo told me when the mail about that meeting had come out that he'd already tried such a setup in the past (I didn't know that when we were in Helsinki, but it was before that), and that his setup, IIRC, was in fact slower than a native build because of the overhead of the network call to start the compiler--At least that's how I recall his explanation. I don't remember the details; if you have any questions, please ask him. Now it might be that with faster hardware (I don't know the specifics of Ingo's setup; I seem to recall he mentioned a Pentium III-class system as the distcc host, but I might be delirious) the distcc stuff will indeed work better, but if such a setup with a not /that/ old system is already slower than a native build, then I'm not very hopeful that a distcc setup is going to get us much benefit, while it _will_ give us a huge overhead. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
