April 13, 2011 at 10:08Alternate build environment for N900
Currently, there is the only official way to compile for the N900 - through Scratchbox. How did he not please me? Yes, here's the thing. Firstly, it is only available under i386, with all the fun that follows from this in the form of the need to keep a bunch of 32-bit libraries. Secondly, it is put contrary to all the canons for some reason in / scratchbox, simultaneously registering its modules for binfmt and, doing up other mischief, destroys the harmonious distribution structure. Thirdly, there is quite ancient qemu, which gives by no means a record compilation speed. And fourthly, this miracle is installed very slowly (I don’t know where they are hosted, but the installer downloaded half a packet of packets for a rather long time. By the way, it weighs a lot in the installed form, and there is also an SDK on top of it.
Well, the most important thing. qemu-user does not support the entire set of kernel system calls. And that means that part of the software (in particular, mono) will not be able to work corny. The problem could be solved by chrooting into the environment from the arm system in the full emulation mode, but see point one.
In general, a miserable sharing, I can’t imagine at all whose hand raised the idea of using it in a serious project.
In principle, you can still compile directly on the device. But here the problem is that busybox is standing there, with which the same dpkg-buildpackage is very bad friends. Accordingly, when transferring rootfs from the device and trying to use it, this rake does not disappear anywhere. And replacing it with coreutils is not so simple, because it will break part of the dependencies and fall off the half-system.
And what to do? And we will go the other way. We will pose as ardent followers of Baron Munchausen and, in the best traditions of the bootstrap procedure (lifting oneself by the shoe laces), we will install the system from scratch from the packages. How exactly, read under the cut.
Actually, you need to get hold of and make the heart of any distribution based on Debian - the APT package management system - work. And only then with apt-get you can install everything else. But dpkg is required for its operation. And dpkg needs at least some basic environment to start. Generally speaking, in normal distros, debootstrap does the rough work of creating it, but we do not have scripts for it for Maemo. So the easiest way to do this is with your hands.
First, you need this same dpkg installed in the main system. If you do not have something based on Debian, then you should not worry, dpkg is in the repositories of almost all distributions. In addition to this, we need to somehow chroot-go into the "guest" system. For these purposes, there is a qemu-user utility (which, incidentally, is mercilessly exploited by the scratchbox mentioned above), which, being known to the binfmt kernel module, allows you to run binaries for other architectures directly on the current kernel, emulating the processor and properly translating system calls (syscall) . Everywhere packages are named differently, but we need a qemu-arm-static file and something that will write it where necessary. In Ubuntu, the package you need is called qemu-kvm-extras-static.
In addition, we will need to get 8 deb packages. libc6, gcc-4.2-base, libgcc1, perl-base, sysv-rc, dpkg, libstdc ++ 6 and apt. Yes, only 8 packages are needed to lift the system from scratch. You can safely deflate them by looking at maemo.org/packages. Although no, I'm lying. The contents of these packages, as they say, "will not take off" in the absence of such basic things as sh, ln, rm, etc. And they lie in coreutils. And coreutils is also not installed just like that and wants a bunch of all kinds of differences. How to be
The aforementioned busybox comes to the rescue. Moreover, the version from Maemo is not interesting to us, it also needs libraries. Therefore, we stomp on ports.ubuntu.com (well, or with debian.org you can, as you like) and pull out a package with a statically linked business box from there. He generally does not need anything other than the kernel system call interface. Thing in itself. We parse the package using dpkg -x and pull out the desired executable from there.
Well, now everything is ready and we can proceed.
First, create a directory for the future system and drop qemu there (since we will be doing chroot, it must be inside, otherwise the miracle will not work).
Now we throw in / bin copies of the biziboksa. Utilities from coreutils and other packages will then overwrite them, but now they are vital.
Now we need to create a minimal set of directories, without which dpkg of the main system can not do anything with the "guest":
How to put packages now? Yes, simple. Dpkg has the --root parameter, which makes it work, considering the specified directory as the root. Very helpful. In general, he should swear at the mismatch of architectures (you have the main system not on ARM there?), So let's say --force-architecture
In theory, he should report that everything is successful. Now we will mount / dev / pts to the guest, because when installing some packages it is needed.
All you can do is chroot root / bin / sh. Now we are in the newly created system. It is still empty here and practically nothing works. Now we need to install APT. We set the dpkg already present in the system on the remaining two packages previously copied into it. First we set the locale in C, because we do not have locales here yet.
Now we register DNS in resolv.conf. I usually put 8.8.8.8, but then not for everyone. We also bring sources.list to the following form:
We sit, wait, while apt-get quickly downloads and installs packages. When asked whether to overwrite resolv.conf, send the forest. At the output we get a compact (about 200 megabytes, about 60 pumped out from the network in general) environment, into which you can safely chroot and compile all sorts of differences there. And all this without Scratchbox's different curves. The only thing I can do is use Xephir, but I'm somehow closer to hardware debugging. If you wish, you can deploy the same system in the i386-version, the process is no different, but the X-server should pick up.
After the above steps, you may need to go herein order to gain access to proprietorship (in particular, OpenGL libs, without them Qt is not installed). By the way, nokia-binaries and nokia-apps must be installed through aptitude. apt-get is not able to resolve dependencies for some reason.
I remind you that in qemu-user mode some set of software does not work. I strongly recommend using qemu-arm-system, pitting it on an image with normal Linux assembled under ARM, and from there run chroot. The image of Ubuntu you can do here on this a manual , there is no big deal. But for ordinary GCC, qemu-user is more than enough.
Thank you for your attention, see you soon.
Archive with packages and installer script
Well, the most important thing. qemu-user does not support the entire set of kernel system calls. And that means that part of the software (in particular, mono) will not be able to work corny. The problem could be solved by chrooting into the environment from the arm system in the full emulation mode, but see point one.
In general, a miserable sharing, I can’t imagine at all whose hand raised the idea of using it in a serious project.
In principle, you can still compile directly on the device. But here the problem is that busybox is standing there, with which the same dpkg-buildpackage is very bad friends. Accordingly, when transferring rootfs from the device and trying to use it, this rake does not disappear anywhere. And replacing it with coreutils is not so simple, because it will break part of the dependencies and fall off the half-system.
And what to do? And we will go the other way. We will pose as ardent followers of Baron Munchausen and, in the best traditions of the bootstrap procedure (lifting oneself by the shoe laces), we will install the system from scratch from the packages. How exactly, read under the cut.
Actually, you need to get hold of and make the heart of any distribution based on Debian - the APT package management system - work. And only then with apt-get you can install everything else. But dpkg is required for its operation. And dpkg needs at least some basic environment to start. Generally speaking, in normal distros, debootstrap does the rough work of creating it, but we do not have scripts for it for Maemo. So the easiest way to do this is with your hands.
First, you need this same dpkg installed in the main system. If you do not have something based on Debian, then you should not worry, dpkg is in the repositories of almost all distributions. In addition to this, we need to somehow chroot-go into the "guest" system. For these purposes, there is a qemu-user utility (which, incidentally, is mercilessly exploited by the scratchbox mentioned above), which, being known to the binfmt kernel module, allows you to run binaries for other architectures directly on the current kernel, emulating the processor and properly translating system calls (syscall) . Everywhere packages are named differently, but we need a qemu-arm-static file and something that will write it where necessary. In Ubuntu, the package you need is called qemu-kvm-extras-static.
In addition, we will need to get 8 deb packages. libc6, gcc-4.2-base, libgcc1, perl-base, sysv-rc, dpkg, libstdc ++ 6 and apt. Yes, only 8 packages are needed to lift the system from scratch. You can safely deflate them by looking at maemo.org/packages. Although no, I'm lying. The contents of these packages, as they say, "will not take off" in the absence of such basic things as sh, ln, rm, etc. And they lie in coreutils. And coreutils is also not installed just like that and wants a bunch of all kinds of differences. How to be
The aforementioned busybox comes to the rescue. Moreover, the version from Maemo is not interesting to us, it also needs libraries. Therefore, we stomp on ports.ubuntu.com (well, or with debian.org you can, as you like) and pull out a package with a statically linked business box from there. He generally does not need anything other than the kernel system call interface. Thing in itself. We parse the package using dpkg -x and pull out the desired executable from there.
Well, now everything is ready and we can proceed.
First, create a directory for the future system and drop qemu there (since we will be doing chroot, it must be inside, otherwise the miracle will not work).
mkdir -p root / usr / bin
cp / usr / bin / qemu-arm-static root / usr / bin
Now we throw in / bin copies of the biziboksa. Utilities from coreutils and other packages will then overwrite them, but now they are vital.
mkdir -p root / bin
cp busybox root / bin / sh
cp busybox root / bin / ln
cp busybox root / bin / touch
cp busybox root / bin / chmod
cp busybox root / bin / chown
cp busybox root / bin / cp
cp busybox root / bin / tar
cp busybox root / bin / rm
cp busybox root / bin / gzip
cp busybox root / bin / grep
Now we need to create a minimal set of directories, without which dpkg of the main system can not do anything with the "guest":
mkdir root / etc
mkdir -p root / var / lib / dpkg
mkdir root / var / lib / dpkg / tmp.ci
mkdir root / var / lib / dpkg / updates
mkdir root / var / lib / dpkg / info
mkdir -p root / var / log
mkdir -p root / dev / pts
touch root / var / lib / dpkg / status
touch root / var / lib / dpkg / available
touch root / etc / ld.so.conf
mkdir / var / backups
touch / var /backups/infodir.bak
How to put packages now? Yes, simple. Dpkg has the --root parameter, which makes it work, considering the specified directory as the root. Very helpful. In general, he should swear at the mismatch of architectures (you have the main system not on ARM there?), So let's say --force-architecture
export DPKG = "dpkg --force-architecture --root = root -i„
$ DPKG packages / libc6_2.5.1-1eglibc27 + 0m5_armel.deb
$ DPKG packages / gcc-4.2-base_4.2.1-4maemo13 + 0m5_armel.deb
$ DPKG packages / libgcc1_4.2.1-4maemo13 + 0m5_armel.deb
$ DPKG packages / perl-base.deb
$ DPKG packages / dpkg_1.14.25maemo3 + 0m5_armel.deb
$ DPKG packages / sysv-rc_2.85-22.osso15_all.deb
In theory, he should report that everything is successful. Now we will mount / dev / pts to the guest, because when installing some packages it is needed.
mount --bind / dev / pts root / dev / pts
All you can do is chroot root / bin / sh. Now we are in the newly created system. It is still empty here and practically nothing works. Now we need to install APT. We set the dpkg already present in the system on the remaining two packages previously copied into it. First we set the locale in C, because we do not have locales here yet.
export LC_ALL = C
dpkg -i libstdc ++ 6_4.2.1-4maemo13 + 0m5_armel.deb
dpkg -i apt_0.7.20.2maemo13.1 + 0m5_armel.deb
Now we register DNS in resolv.conf. I usually put 8.8.8.8, but then not for everyone. We also bring sources.list to the following form:
deb http_: //repository.maemo.org/extras/ fremantle-1.3 free non-free
deb http_: //repository.maemo.org/extras-testing/ fremantle-1.3 free non-free
deb http_: //repository.maemo .org / extras-devel / fremantle-1.3 free non-free
deb http_: //repository.maemo.org/ fremantle / sdk free non-free
apt-get update
apt-get --allow-unauthenticated -y install apt-transport-https coreutils tar build-essential gzip grep bash aptitude libgtk2.0-dev
apt-get clean
We sit, wait, while apt-get quickly downloads and installs packages. When asked whether to overwrite resolv.conf, send the forest. At the output we get a compact (about 200 megabytes, about 60 pumped out from the network in general) environment, into which you can safely chroot and compile all sorts of differences there. And all this without Scratchbox's different curves. The only thing I can do is use Xephir, but I'm somehow closer to hardware debugging. If you wish, you can deploy the same system in the i386-version, the process is no different, but the X-server should pick up.
After the above steps, you may need to go herein order to gain access to proprietorship (in particular, OpenGL libs, without them Qt is not installed). By the way, nokia-binaries and nokia-apps must be installed through aptitude. apt-get is not able to resolve dependencies for some reason.
I remind you that in qemu-user mode some set of software does not work. I strongly recommend using qemu-arm-system, pitting it on an image with normal Linux assembled under ARM, and from there run chroot. The image of Ubuntu you can do here on this a manual , there is no big deal. But for ordinary GCC, qemu-user is more than enough.
Thank you for your attention, see you soon.
Archive with packages and installer script