* acrux (acrux_it@libero.it) wrote: [...]
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).
ok, that's just a small abstract about what i did in June to bump from gnueabi (crux arm) to gnueabihf (crux armhf). I hope that my sum-up can help you to "normalize" my work in a Makefile.
This last week I put hands on hardfp and there is a little development born from the first Makefile with hardfp suppport I did in May and a mix with your patches.
1) after a fresh crux arm 2.7-test1 installation (i always worked natively i.e. directly using the efikamx) i bumped the toolchain to gcc-4.6.x and glibc-2.13 here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-SOFT/ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-SOFT/src/
You know that we are trying to let other people (may be none will use it, but we try to give the option to all users/developers outhere) build their custom toolchain and then crosscompile at least the core ports. We now provide a cross-build for hardfp too. It needs to be tested directly in the toys (task for this weekend). You can find all the info directly in gitweb and here (prebuilt RC and kernel) http://crux-arm.nu/files/devices/efikamx/hardfp/
2) i now started from scratch (CLFS way) to bump to gnueabihf that's totally incompatible with gnueabi. Ok, my bad i did't keep a trace of my steps neither i did a Makefile like your ones (i'm lazy and i'm not a coder thus i don't use to write scripts for every kind of task i've in my mind...). Anyway i did like an updated CLFS for ARM. I know i'd have written it as it isn't yet in existence i guess because only now ARM achieved enough strenght and a "desktop status" capable to autonomously build sources.
Well, about coding, I can tell you that I'm not a coder either. The Makefiles are the same, or at least really similar. It's a good way to keep things homogeneous and it's good to have a "pattern" to follow to improve them. Your work could be done with some little changes. We follow the "CLFS way" to build the toolchain and it can be seen directly in all toolchain Makefiles. The eglibc discussion is a good one to think about (at least IMHO). Having options is a good thing for developers and users (I tried to start a uclibc toolchain but there is no interest by other people to help/test/develop)
Well this is the point, to bump to gnueabihf i used to do like CLFS that's quite different from a CLFS-sysroot as your standard Makefile does. Or i simply misunderstood your modus operandi and i was in lack of a step using the Makefile approach.
Ok, the step that i needed for was to build a temporary system. From CLFS book: [...] The tools in this chapter are cross-compiled using the toolchain in /cross-tools and will be installed under the ${CLFS}/tools directory to keep them separate from the files installed in Installing Basic System Software and the host production directories. Since the packages compiled here are temporary, we do not want them to pollute the soon-to-be CLFS system. [...]
CLFS really provide a good way to build a custom toolchain and a copuple of needed software to boot a minimal system. We took the toolchain info and built a custom one. For the minimal system, we use CRUX core ports using this toolchain.
After which i was able to succesfully build my full working gnueabihf CLFS system. As i wasn't sure to have a stable system i didn't include graphite support in that toolchain.
3) i transformed that CLFS in a CRUX system. here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/src/
Well, from CLFS i already choosed to use eglibc as this ARM ABI's flavour is better supported.
Here I have been fighting with glibc and seems to be built right but the real test will be when we boot the system.
4) i updated the system and i added the graphite support (with isl built-in backend). here used ports and sources: http://cruxppc.org/~acrux/arm/2.7-HARD/1/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/update/arm-ports.tar.bz2 http://cruxppc.org/~acrux/arm/2.7-HARD/1/src/
This is really interesting. Now with a hardfp release, may be it can be possible to make an overlay for this kind of optimizations and provide a document where we can explain how to act (updating ports and rebuilding the necessary) This will be the next step, but really I need to focus first in getting the system running in a "stable" state.
5) about this toolchain: a stable toolchain for ARM isn't really yet available... http://sourceware.org/ml/binutils/2011-09/msg00162.html http://gcc.gnu.org/ml/gcc/2011-09/msg00361.html
Yes, it's quite new and this will need to be improved. Let's see if the custom toolchain built by our side can give sight to hardfp implementation in any sense. Thank you very much for all your work. It provided a good way to follow in versions and patches used. You can check the Makefile and look that it's really similar to the eabi/noeabi/uclibc ones.
cheers, --nico
Regards, Victor. --- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org