Re: Preparing the m68k port for the future.
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.
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
Reply to: