On 11/22/10 08:31, Victor Martinez wrote:
* Luka Vandervelden (lukc@upyum.com) wrote:
Hi *. \o_ Hey Luka,
Hello and thanks for posting,
I have some questions about Crux-ARM.
First, is a uclibc based toolchain planned???? (and if not, would be Crux-ARM open to accept patches related to that???? for example, allowing to build the toolchain with uClibc depending on the target) At the moment there is no plan to start another toolchain based on uclibc, we are trying to follow CRUX, in this sense, the main focus is to give support to the current versions used in CRUX directly, but in another hand, it could be interesting to make tests with uclibc on some embedded machines.
As pitillo said, we are trying to follow CRUX and toolchain's component to be used, but we are not closed to new ideas (uclibc/eglibc/dietlibc) and we could start another branch (or repository) for trying it. In this case we encourage you to contribute and help us a bit to develop and maintain the new stuff.
Then, is Crux-ARM open to targets other than arm(|el)-*-linux-*???? (say, for example, mips-Crux-linux-uclibc, or i686-Crux-linux-gnu) The main interest wouldn???t be to port Crux to a new architecture, but to have a working Crux toolchain for that architecture. (everybody is not on x86)
Well, I think this isn't aimed. CRUX-ARM is a CRUX port to ARM architecture. In this sense there is no plan to make/give more support to other targets. If you meant to give another hosts support, it could be studied to see if it's possible/interesting to go ahead on this topic (we started with aquadran's help to use ubuntu's hosts to build the entire framework).
Yeah, CRUX-ARM was only intended as a port to ARM, but feel free and go ahead if you think you can adapt the model of development to another architecture (toolchain, pkgmk-cross, cross Pkgfiles, scripts, etc.) Personally I don't have any MIPS device for now, but maybe we could share some infos.
And finally, at least for now, why are there pairs of repositories???? There is one for the packages, and another for the cross-packages. Why not adapt the Pkgfiles to cross-build or not depending on the tool used (pkgmk or cross-pkgmk)???? Or even the options given to this tool (--target arm-... for example).
You are mixing 2 things here. Let's see, packages (cross-packages) are splitted in 2 directories, because we are giving support to arm and arm-eabi (for arm<= armv4t and for arm eabi> armv4t). We keep 2 branches when it's needed, you can see core-cross (ports not packages) and two branches, one per ABI (we keep them splitted to make changes if they are needed between both). We keep native collections to make native builds and we have some of them (atm core/opt/xorg) to make an overlay over the CRUX ports (may be some need to be touched and may be fixed the footprint)
Yeah, as you noted we have 2 flavours (noeabi/eabi, called by debian as arm/armel). We used crosscompilation to release the rootfs, and also some packages just to avoid compiling in small devices, but you are able to compile them yourself natively. To build packages with crosscompilation you'll need: - the toolchain's branch (noeabi/eabi) for your device - some cross-repositories (core-cross.git, opt-cross.git, etc.) - and pkgmk-cross which its used to build packages from Pkgfiles in cross-repositories (just see a Pkgfile from a cross-repo to take an idea, we used more vars like $CLFS, etc.) To build packages with native compilation you'll need: - a working CRUX-ARM installation on a powerfull device (sheeva/guru plug, etc.) - some repositories which are an overlay of CRUX's repos (core.git, opt.git, etc.) I hope this can helps. Best regards, -- Jose V Beneyto | http://sepen.mine.nu/