Clemens Koller wrote:
Hello, Giorgio!
hello Clemens, but weird that you reply to the Crux ML... ;-)
What is the status or what are your plans of a dedicated crux-ppc mailing list?
i did not manage to get a ml from that friend of mine i wrote you about, but i will ask now to Biscottin who registered cruxppc.org some time ago...
If we run into any restrictions, I will just rent a cheap root-server somewhere out there. I need that anyway for several projects anytime soon.
well its up to you... but i don't think that's needed just to get a ML.
Just FYI: I am in the process of recompiling (stage 1) a superset of the current crux-x82-2.2 core, the crux-ppc-cvs core with my own (LFS-like) build history for my embedded mpc8540 powerpc CRUXish distro. [...] root@ecam:/foxdist/ports/core_failed$ ls -la drwxr-xr-x 2 root root 328 Oct 18 21:06 glibc drwxr-xr-x 2 root root 152 Oct 17 22:28 openssh drwxr-xr-x 2 root root 192 Oct 17 23:11 slocate drwxr-xr-x 2 root root 128 Oct 17 23:17 unzip drwxr-xr-x 2 root root 128 Oct 17 23:17 usbutils
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...
glibc-2.3.6 fails with current binutils-2.17 according to a bugreport in the web: http://foo-projects.org/pipermail/lunar-dev/2006-July/005821.html
So, I suspect that glibc-2.3.6 on x86 fails to build, too, once binutils is updated to 2.17. (just compiling now...)
yes it builds fine with binutils 2.16 and doesn't build with 2.17. 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... http://cvs.sunsite.dk/viewcvs.cgi/cruxppc/ports/ppc/core/glibc/
I'll see to what toolchain versions I'll finally stick.
Well i think it might be more useful to join forces instead of doing the same thing twice... 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...
The rest should be considered low-risk. I don't need yaboot and friends, because I boot the kernel out of flash.
Best greets,
bye and have fun ;-) greets to all, giorgio -- NullPointer || GnuPG/PGP Key-Id: 0x343B22E6 http://cruxppc.sunsite.dk