[...]
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).
ummmm let's see how can I explain without sound hard. I hope my words aren't picked in a bad sense. About the image, I think it's really good to personal use (may be to make some tests too, but I can't see any good point about it) but not for development purposes, that's why we try to keep the development in git, from toolchain* to *-cross ports. Having the hardfp development done in a image, can give us a little feedback about performance or stability, but we avoid the fact of letting others do the same. They need to download a full image instead of building it in their own, giving the lot of possibilities we have with the "enviroment". About ilenia, I think it could be really easy to start working with it. Why dont we use a port for it? and then, we can start putting hands on it and verify if it can be an interesting/helpfull app.
Without a binutils-2.22 there isn't a stable hardfp release.
Great. This is interesting, because may be we need to wait a bit more to see all toolchain components more "stable" with hardfp.
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.
True, glibc and glibc-ports are a big problem atm (it happened too with eabi/noeabi toolchain in the past). We can make both options in the same git repo, letting the user choose between both of them, but this will give two scenarios, and this implies two developments (because we can find problems cross-building (or native builing) depending in that choice).
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.
Agree, we can put hands on those new and stable features. They are there to make use of them. If this implies more performance/stability then these are enought reasons to put our efforts in try to make the best. [...]
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.
Sorry, it sounds really a pity. [...]
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.
Yes, this was discussed some time ago too, between Jose and me, and we were lucky when the 2.6 release was done and really synced with CRUX 2.6 toolchain components. Now we have more knowledge and we can put hands on another components filling our needs. [...]
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.
This sounds hard for me in this moment. I need to repick again the hardfp toolchain info I had some time ago and start reading about those components. I don't know so much about them (here I see your knowledge and experience)
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' .
Sorry my lack of knowledge, but I don't understand why we need a hardfp enviroment to build a hardfp enviroment with ppl support. May be this can be explited in some steps and documentation. For example, if we can use the "Makefile" to build a hardfp toolchain with "some" components (like cloog) and then, document it to rebuild it to give ppl support it's better than provide an image IMHO. Being "synced" with obsolete CRUX toolchain isn't a problem. We need other versions to have hardfp, then there is no reason to don't pick the needed ones with the needed patches too. Compiling time isn't a problem really, if it was, then we weren't using CRUX-ARM and we should pick another package oriented distro. [...]
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.
The best solution is comunication (with my bad english can be a pain but I'm trying to make as best as I can) when a project is managed with more than two hands. I really appreciate your work and effort Nico, don't pick my words wrong, or in a bad sense please. I try to explain my point of view to look for the best solution for developers and users. Thank you very much for all your info, work, feedback, help... in resume we really appreciate all you are giving to this little project.
cheers, - --nico
Regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org