On Mon, 26 Sep 2011 16:47:01 +0200 Victor Martinez <pitillo@crux-arm.nu> wrote: _omissis__
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
it's fine, don't worry. I choose to release it as image, source and ports archive only to avoid the feeling of "official release" of something other like a fork.
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".
i did it to save your time while you were working on (high priority) 2.7 release. You can use it as start environment to bootstrap a new clean system as you use to do with the 'Makefile' practice.
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.
there was an ilenia port but the author removed it when he went out from CRUX members group. Then he joined to CRUX PPC project and added some nice features to manage our arch overlay. He also did our first biarch (ppc and ppc64) toolchain. You can find actual ilenia's port here: http://cruxppc.org/viewvc/core/branches/2.7/ilenia/
From long time I don't use any GNU/Linux distro (i only need/use MS Windows) on my x86_64 workstation/laptop thus i'll never share my ports with CRUX main project as i cannot test them on x86. That's why i maintain some ports only on CRUX PPC. E.g., CRUX PPC always had ports to build gnash, icedtea or openoffice.
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.
binutils-2.21.90 is out thus i guess a stable release is in the next future...
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).
too much complicated to handle for a small team. And to be realistic a standard enduser doesn't care too much if there is glibc or eglibc... The situation, today with 2.14 release, is simple... with eglibc you can release eabihf/eabi/noeabi with glibc only eabi/noeabi. But it's always possible to wait for a new glibc release.
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.
cloog/ppl are modern features that you can optionally enable with appropriate compiler flags. I say, you can have toolchain's components (gcc/binutils) with these features but simply avoiding to use them. _omissis__
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.
as my experience (with ppc) sometimes you are obliged to not be totally aligned 'cause, as common example, the toolchain needs different love on your own arch. cheers, --nico -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/