Alternative build environment for the N900
At the moment there is the only official way to compile under the N900 - through Scratchbox. What he did not please me? Yes, that's what. Firstly, it is only under i386, with all the amusingness arising from this as the need to keep a bunch of 32-bit libraries. Secondly, it is put against any canons for some reason in / scratchbox, along the way prescribing its modules for binfmt and, getting up other obscene things, destroys the slender structure of the distribution. Thirdly, there is quite an ancient qemu, which does not give a record compilation speed. And fourthly, this miracle is put very slowly (I don’t know where they are hosted, but the installer has been downloading half a pack of packages for quite a long time. By the way, it also weighs pretty well in the installed form. And the SDK is still on top.
Well, the most important thing. qemu-user does not support the entire set of kernel system calls. And, therefore, part of the software (in particular, mono), corny will not work. The problem could be solved by chrooting to the environment from the arm system in full emulation mode, but see point one.
In general, the poor part is, I don’t even know who had raised his hand to use it in a serious project.
In theory, you can still compile directly on the device. But here the problem is that there is a busybox, with which the same dpkg-buildpackage is very bad friends. Accordingly, when transferring rootfs c devices and attempts to use it, these rakes do not disappear anywhere. And to replace it with coreutils is not so easy, because it will break a part of dependencies and half the system will fall off.
')
And what to do? And we will go the other way. Let's pose as ardent followers of Baron Munchhausen and, in the best traditions of the bootstrap procedure (raising oneself by the shoelace), install the system from scratch from the packages. How exactly, read under the cut.
Actually, it is necessary to get hold of and make the heart of any Debian-based distribution kit work - the APT package management system. And then with the help of apt-get you can install everything else. But for his work dpkg is needed. And dpkg needs at least some basic environment to start. Generally speaking, in normal distractions, debootstrap does the rough work to create it, but we do not have scripts for it for Maemo. So the easiest way to do this is with your hands.
To get started, you need this very 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, we need to somehow chroot into the "guest" system. For these purposes, there is a qemu-user utility (which, incidentally, mercilessly exploits the scratchbox mentioned above), which, being known to the kernel module binfmt, allows you to run binaries for other architectures directly on the current kernel, emulating a processor and how to broadcast system calls (syscall) . Everywhere packages are called differently, but we need a file qemu-arm-static and something that it will prescribe where necessary. In Ubuntu, the required package 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 raise the system from scratch. They can be safely deflated by searching maemo.org/packages. No, I'm lying. The contents of these packages, as they say, “will not fly up” in the absence of such basic things as sh, ln, rm, etc. And they lie in coreutils. And coreutils is also not put in just like that and wants a bunch of all sorts of differences. How to be?
The aforementioned busybox comes to the rescue. And the version from Maemo is not interesting for us, it also needs libraries. Therefore, we stamp on ports.ubuntu.com (well, or with debian.org, you can, as you like) and pull out a package with statically linked bizybox. It doesn't need anything other than the kernel system call interface. A thing in itself. Parse the package using dpkg -x and pull out the desired executable file from there.
Well, now we have everything ready and you can proceed.
To begin with, we will create a directory for the future system and throw qemu there (since we are going to chroot, it must be inside, otherwise the miracle will not work).
Now we throw a copy of the bizybox in / bin. They will then be overwritten with utilities from coreutils and other packages, but now they are vital.
Now you need to create a minimal set of directories, without which the main system dpkg can not do anything with the “guest”:
How to put the packages now? Yes, just. Dpkg has a --root option that makes it work, considering the specified directory as the root. Very useful. In general, he should swear about non-compliance of architectures (you don’t have a basic system 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.
That's it, you can chroot root / bin / sh. Now we are in the newly created system. It is still empty and practically nothing works. Now we need to install apt. Pit already existing in the system dpkg on the remaining two packages previously copied into it. Pre-set the locale to C, because we don’t have a locale here yet.
Now we register DNS in resolv.conf. I usually put 8.8.8.8, but here on the fan. We also bring sources.list to the following form:
Sit, wait, while apt-get promptly 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 of the network in general) environment into which you can chroot and compile there any differences. And all this without different Scratchboxes curves. The only thing to take advantage of Xephir'om navryatli, but I somehow closer debugging on the hardware. If you wish, you can deploy the same system in the i386 variant, the process is no different, but the X server must pick up.
After the above steps, you may need to go here in order to gain access to proprietary (in particular, OpenGL libs, Qt is not installed without them). By the way, nokia-binaries and nokia-apps need to be installed via aptitude. apt-get is not able to resolve dependencies for some reason.
I remind you that in the qemu-user mode some set of software does not work. I strongly recommend using qemu-arm-system, setting it to the image with the normal Linux compiled under ARM, and then from there to chroot. The image of ubunt can be done here on this manual , there is nothing complicated. But for the usual 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, therefore, part of the software (in particular, mono), corny will not work. The problem could be solved by chrooting to the environment from the arm system in full emulation mode, but see point one.
In general, the poor part is, I don’t even know who had raised his hand to use it in a serious project.
In theory, you can still compile directly on the device. But here the problem is that there is a busybox, with which the same dpkg-buildpackage is very bad friends. Accordingly, when transferring rootfs c devices and attempts to use it, these rakes do not disappear anywhere. And to replace it with coreutils is not so easy, because it will break a part of dependencies and half the system will fall off.
')
And what to do? And we will go the other way. Let's pose as ardent followers of Baron Munchhausen and, in the best traditions of the bootstrap procedure (raising oneself by the shoelace), install the system from scratch from the packages. How exactly, read under the cut.
Actually, it is necessary to get hold of and make the heart of any Debian-based distribution kit work - the APT package management system. And then with the help of apt-get you can install everything else. But for his work dpkg is needed. And dpkg needs at least some basic environment to start. Generally speaking, in normal distractions, debootstrap does the rough work to create it, but we do not have scripts for it for Maemo. So the easiest way to do this is with your hands.
To get started, you need this very 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, we need to somehow chroot into the "guest" system. For these purposes, there is a qemu-user utility (which, incidentally, mercilessly exploits the scratchbox mentioned above), which, being known to the kernel module binfmt, allows you to run binaries for other architectures directly on the current kernel, emulating a processor and how to broadcast system calls (syscall) . Everywhere packages are called differently, but we need a file qemu-arm-static and something that it will prescribe where necessary. In Ubuntu, the required package 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 raise the system from scratch. They can be safely deflated by searching maemo.org/packages. No, I'm lying. The contents of these packages, as they say, “will not fly up” in the absence of such basic things as sh, ln, rm, etc. And they lie in coreutils. And coreutils is also not put in just like that and wants a bunch of all sorts of differences. How to be?
The aforementioned busybox comes to the rescue. And the version from Maemo is not interesting for us, it also needs libraries. Therefore, we stamp on ports.ubuntu.com (well, or with debian.org, you can, as you like) and pull out a package with statically linked bizybox. It doesn't need anything other than the kernel system call interface. A thing in itself. Parse the package using dpkg -x and pull out the desired executable file from there.
Well, now we have everything ready and you can proceed.
To begin with, we will create a directory for the future system and throw qemu there (since we are going to 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 a copy of the bizybox in / bin. They will then be overwritten with utilities from coreutils and other packages, 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 you need to create a minimal set of directories, without which the main system dpkg 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 the packages now? Yes, just. Dpkg has a --root option that makes it work, considering the specified directory as the root. Very useful. In general, he should swear about non-compliance of architectures (you don’t have a basic system 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
That's it, you can chroot root / bin / sh. Now we are in the newly created system. It is still empty and practically nothing works. Now we need to install apt. Pit already existing in the system dpkg on the remaining two packages previously copied into it. Pre-set the locale to C, because we don’t have a locale 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 here on the fan. 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
Sit, wait, while apt-get promptly 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 of the network in general) environment into which you can chroot and compile there any differences. And all this without different Scratchboxes curves. The only thing to take advantage of Xephir'om navryatli, but I somehow closer debugging on the hardware. If you wish, you can deploy the same system in the i386 variant, the process is no different, but the X server must pick up.
After the above steps, you may need to go here in order to gain access to proprietary (in particular, OpenGL libs, Qt is not installed without them). By the way, nokia-binaries and nokia-apps need to be installed via aptitude. apt-get is not able to resolve dependencies for some reason.
I remind you that in the qemu-user mode some set of software does not work. I strongly recommend using qemu-arm-system, setting it to the image with the normal Linux compiled under ARM, and then from there to chroot. The image of ubunt can be done here on this manual , there is nothing complicated. But for the usual GCC, qemu-user is more than enough.
Thank you for your attention, see you soon.
Archive with packages and installer script
Source: https://habr.com/ru/post/117364/
All Articles