* Luka Vandervelden (lukc@upyum.com) wrote:
On Mon, Nov 22, 2010 at 09:16:55AM +0100, Jose V Beneyto wrote:
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.
Ok, I already started to adapt the cross-toolchain to use uClibc. I would be happy to share my modifications, if working. :)
Feel free to share it if you want us to take a look and if we have some free time may be start helping you developing/testing/debugging it. If we make it build right, we can start trying cross-compilations based on ucibc and learn about.
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.
Yes, so I will start to see if I can cross-compile for my own netbook (x86) and after that see if cross-compilation for MIPS is possible. (I have a Neufbox/Ninebox which uses such CPU, so I may test in the future??? when I???ll have the UART port /o\)
CRUX-MIPS on the way? :)
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.)
In fact, I was wondering why the cross-ports and the ???normal??? ports are not the same. I think the Pkgfiles could be adapted to know whether they are cross-compiling or not, by the configuration, pkgmk command line or other, and then to build correctly????
We can split the work in 2 parts, not all people will cross-build ports, may be with the release and "strong" hardware it's better to use CRUX's ports collections or directly our overlays. It'll use CRUX pkgutils nor pkgutils-cross. CRUX-ARM's aim: CRUX in ARM devices. In this sense, we keep them separated and Pkgfile more "clean" (atm cross ports aren't really clean, but in a future using host's pkg-config all the exported dependencies vars will be avoided) Think that pkgmk must be more patched, and it must know where to to install ports. This is one the reasons why I feel more confortable using another pkgutils, I don't want to install/touch/break the host with a cross-port (there are crosstools ports for CRUX) and force people to patch/install pkgutils in their hosts (ubuntu for example?) I don't see a reason to make pkgutils grow more really, with pkgutils-cross we can manage the system quite well and far from the host's system. Like said above, the aim is to use CRUX's pkgutils in the targets.
I hope this can helps. Yes, thanks. :)
Lukc _______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu http://crux-arm.nu/mailman/listinfo/crux-arm
Learning bit by bit Victor Martinez | http://lokalix.dyndns.org