* acrux (acrux_it@libero.it) wrote:
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.
Yeah I understand it, but without knowing about how to replicate it, it's hard for others to start working with it. This is the reason why we try to manage with those "Makefiles", letting others build in their own and look for build problems (or test problems too).
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.
Well, that's a very good effort, but we can't see how do you managed it. In other sense, it would be great to let you work directly in a git repo dedicated for hardfp. We were working in the old 2.6 release (looking for problems, building ports and packages) and we had in the other hand the start point to the 2.7 release development. I can't see a problem there, if you had begun a work in hardfp while we were putting hands on closing 2.7 release. This is the reason to have Makefiles, we can keep track of the work progress, we have revision control, others can pick the work and start from there...
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/
Well, it's a really interesting app to manage ports and packages. We are trying to avoid the package generation and management, letting it to users directly (there are lot of options to use packages in a farm enviroment for example, but it's known that CRUX is source oriented, and ilenia can make things more confortable to a group of users in this sense) It could be great to add it to our ports collection. But overlays are managed like is done in CRUX x86_64b, having some "love" needed ports splitted in the current *-arm ports collections.
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.
Sounds reasonable.
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...
We can give some more time to it without problem. I have other things between hands too but I'm excited about the performance bump got with hardfp support.
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.
And while we wait, we can start the development based on eglibc and verify how compilation ports go. We can check if we find concrete ports build or something else.
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.
If they can give something good (performance, security, stability...) then those are things to take care and we need to think about adding them to the current toolchain (in case it can be done directly at toolchain level and study the possibilities to add more support from the ports collection, in case of ppl like you said)
_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.
There is no problem to go ahead without being "synced" with CRUX components. Let's try to put hands on hardfp from scratch and build a custom toolchain based on the "needed/current" components version and study this possibility.
cheers, --nico Regards, Victor.
--- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org