crux-ppc mailing list status, new distro fork (was: Re: CRUX from LFS)
clemens.koller at anagramm.de
Thu Oct 19 14:35:55 UTC 2006
Giorgio Agrelli wrote:
> with unzip just tell linux_noasm to the makefile (see crux-ppc cvs), with the
> other ports i don't know... they build allright to me... maybe you only get a
> footprint mismatch??? but that would be werid too...
Thanks, I just ran out of time to check those...
>>So, I suspect that glibc-2.3.6 on x86 fails to build, too, once
>>binutils is updated to 2.17. (just compiling now...)
My guess was wrong.
As of yesterday night, glibc-2.3.6 built on x86 with binutils-2.17 without
any obvious problems.
> As you can see on our CVS the problem is solved with a patch, the only arch
> where that patch is not needed is x86 as you will run in to the same error on
> sparc, mips and so on...
Thank you, too. I'll start to work with your cvs tree as soon as my
environment is ready for it. (I have to solve some
infrastructure / rsync problems on my multiple ppc systems first).
> Well i think it might be more useful to join forces instead of doing the same
> thing twice...
Sure! I just didn't expect that my embedded stuff is so similar and simple
to port from crux-x86 and crux-ppc. :-)
(Just thinking about a single LiveCD which installs to ppc as well as x86 :-)
The CPU here is an MPC8540 PowerPC with an e500 core, which has an SPE
(Signal Processing Engine (=some fixpoint stuff)) instead of an Altivec unit.
> i started to work some time ago on a new toolchain with gcc 4.1
> and glibc4 but then i stopped as it was too different from crux-2.2 toolchain.
> Anyway such a toolchain should give a sharp advantage on processors with
> altivec and on the top of that we could try libfreevec and other
> altivec-related amenities...
Hmm, I remember that I've read something about that some time ago.
Anyway, we should think about glibc4+gcc4.2. Well, it's just a bunch of
work to do, but doable.
R&D Imaging Devices
More information about the CRUX