-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 23 Sep 2011 13:16:37 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote: _omissis__
- From this email: http://crux-arm.nu/pipermail/crux-arm/2011-July/000086.html i only did some minor updates. And my work was still focused on the new toolchain that is really advanced and actually better than cruxppc one i used as start point (and it already has graphite support from 2.6 release).
This can be a good start point, but I would like to discuss some things between all developers. We need to put a direction to follow. I mean, that we need to talk about which versions we should use, if we should stick with glibc (which I think is the way to go but not the only one), which support we can add in the toolchain (cloog, graphite, ...) and how we can improve the toolchain to gain the best hardfp support.
Please give a try with the provided image (well, it's just my smarttop) and testing some ilenia features (/etc/ilenia.conf is the pre-configured file). Without a binutils-2.22 there isn't a stable hardfp release. I switched from glibc to eglibc because glibc doesn't support hardfp and you should apply a good numbers of patches (maybe from MeeGo project they are available). Anyway altough glibc-2.14 is available from June the glibc-ports-2.14 archive there isn't yet. About graphite support and is new cloog (with isl built-in backend instead cruxppc still uses the old clogg-ppl now deprecated from gcc developers) gcc's interface. A guess a modern os should avoid to remove from gcc his own best and innovative (and now stable) feature.
Everything is always available, the server was offline a couple of weeks ago 'cause a disk failure but i successfully repaired it and the raid5 helped me a lot.
Yeah, I tried to get some info this summer (here) and it was impossible. It's great to have it up again.
eh,eh... here in Italy there was CRUX PPC interview on an important Mac magazine and the website was down.. LOL, such a shame. We lost a lot of contacts and new potential users.
- From July Just some minor update i did: *) binutils is now 2.21.53-20110722 and we always must wait for the upcoming 2.22 stable release ;
Agreed with this. I like the idea to use stable releases (and try to be together with CRUX versions too)
thus you should wait for the next CRUX 3.0 to be aligned with the main project. But I'd say CRUX ARMHF is simpled unaligned becouse is unstable without a stable toolchain so nevermaind.
*) file-5.09 fixes arm/ppc bugs thus no fedora's patches are needed anymore ; *) cloog is now 0.16.3 ; *) i rebuilt gcc and binutils against the new cloog-0.16.3 (ABI changed) ; *) i've updated the kernel to 3.1.0-rc6+ but audio and sdma are still unable to work and rtc is not perfect.
If you like at once to work on hardfp i'll upload asap the new cloog,gcc and binutils packages.
Well, I want to start the development... with a new toolchain-hardfp repo. Packages at the moment aren't important. We need to start putting hands on the enviroment, letting others build their own hardfp toolchain, like is done in all releases. May be this way to do things, isn't enought (or you just don't like it) but I think it's the more confortable for all, developer and users.
I uploaded the updated packages and ports: http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/ if, instead, you prefer to update by yourself cloog then you must remeber to do some symlinks to fix the abi changes and rebuild gcc/binutils (about 15h). Then remove the symlinks that are now only garbage. To build an environment with the 'Makefile' you need to already have the working hardfp environment. I was obliged to start from scratch to build a clean and native environment. I started updating the CRUX ARM 2.7rc1 toolchain to a modern one (not aligned to the now obsolete 2.7 main project) then the following step was a simple toolchain without graphite because ppl (Parma Polyhedra Library) is really long to compile i.e. about 20h on 1GHz cpu. Then i successfully built a new toolchain with graphite support. Really really stable. Btw, every toolchain related Pkgfile has 'make check' . _omissis__
As i've understood if rtp's patches were rediffed/reworked at the same time of the last 'for-next' commit you'll have a perfect experimental kernel.
This is a very good info too, but like we talk yesterday, I think we need to start from a stable point. Making some tests with the "stable" kernel and putting newers/testing kernels to a side until we'll have a strong base (toolchain). If we need this kernel (or another one) to give better hardfp support, then this is another history.
yes, it's a valid solution of course. cheers, - --nico - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk58hnEACgkQxq34tDeO7LhsKwCfWlSsg24LoPM4iwFong5NNgn+ bWwAn23Ud7hcAPZpSglVuY+dHLvvA+J5 =rQZx -----END PGP SIGNATURE-----