Mono and Windows Forms on the Nokia N900? Sure, not a problem!
I was somewhat surprised not to see mono in the repositories for this wonderful device. But, since it was desperately needed, I decided to collect it. And then he ran into a very funny feature of the maemsky SDK, which did not allow me to do this. But first things first. In the meantime, a small screen of what happened:
Instead of a normal device emulator and toolchain for assembly, the guys from nokii adapted a scratchbox for this case, which, exploiting qemu-user, runs the arm binaries directly on the core of the current OS. And everything would be great if it worked as it should. In fact, during assembly, qemu issues an “unsupported syscall 242”, after which the assembly stops. It’s difficult to do anything with an ordinary cross-caper, for mono, in the best traditions of the bootstrap procedure (raising oneself by the shoe laces), compiler first compiler and already with its participation is collecting all the rest. How to deal with this is not very clear, if only to compile on the device, but there it will take years. For the N800 mono, some hero was able to collect, but it refused to work on the n900, falling out with SIGSEGV. If anyone is interested in how this problem has been solved, or you can independently touch the mono on the device (you can write directly in Visual Studio, if that) I ask under the cat.
To begin, I will describe how to do it failed . However, experience was obtained and the information can be very useful.
I will not write about the SDK, about its installation and configuration, and without me much has been written.
')
First we need to pull out the uncut rootfs itself. There are 2 ways. First, you can unpack the flasher firmware (flasher-3.5 -u -F IMAGE) and mount rootfs.jffs. In fact, there are not jffs, but ubifs, by the way. I got here on this manual .
You can also load the recovery system, as described here . There, this image is used in order to move sections, but we do not need it. After that, in the internal console, we mount -t ubifs ubi: rootfs / mnt and merge everything onto a USB flash drive. A good backup method, by the way, is highly recommended.
Further on a manual we make to ourselves an image for qemu.
In order to make life easier for you and to be able to chroot into the armor environment, you will need the qemu-kvm-extras-static package. Copy after installing / usr / bin / qemu-arm-static to / bin your system and the chroot starts to work in a magical way. If anyone is interested in how this happens, they can read about binfmt_misc and other goodies that linux allows us. Theoretically, this can be done on the ubuntu x86 device itself in the chroot environment, and in it start the wine. Although, most likely it will not work, for we will come across all the same unsupported system calls.
We are assembling, creating the maemo directory, expanding the image that we have dumped, then everything is on the first pancake.
As a result, during the compilation, mcs began to crash with an internal error and I could not do anything about it. Nevertheless, the build environment was obtained independent of the scratchbox (which, among other things, is also only under i386 ).
On the third day, the Sharp-eyed Eye noticed that the shed had no wall. Namely: almost all mono is managed dll-ki, which absolutely all the same under which platform they are launched. As a result, the following plan matured:
Actually, the fourth step was facilitated by the presence of the option --disable-mcs-build, which the uncle from Novell specifically invented for such cases. I will not describe the build process, this time (after 5 unsuccessful attempts!) Turned out to be quite trivial.
The bundles and versions of libraries in Maemo and Ubunt are somewhat different, so I had to pick them up. But it's worth it: I managed to transfer to the device the normal system scattered across the library packages (not fully yet, but I'm working on it) instead of the 260-meter tarball, which is generated by ./configure && make. Actually, now mono I have devoured about 27 meters / opt with the weight of packages at 12. At the same time, almost the entire .NET 2.0 is already available:
You can install this miracle on your device by adding the following line to sources.list:
and installing the libmono-winforms2.0-cil package, which will pull everything else along. Unfortunately, I haven’t transferred any more packages for now, for it is already 4 am, but I will definitely take care of this later (I’ll transfer gtk software).
If someone wants to transfer their software to C # on the N900 using this assembly, please contact me to keep you informed.
And do not judge strictly for spelling with punctuation, night in the yard, eyes are red, I really want to sleep, and I barely get to the keys.
UPD: With the help of scrap and some kind of mother, GTK # was moved (not everything yet). Well, not such a piece of mono, necessary for the package mono-devel.
Instead of a normal device emulator and toolchain for assembly, the guys from nokii adapted a scratchbox for this case, which, exploiting qemu-user, runs the arm binaries directly on the core of the current OS. And everything would be great if it worked as it should. In fact, during assembly, qemu issues an “unsupported syscall 242”, after which the assembly stops. It’s difficult to do anything with an ordinary cross-caper, for mono, in the best traditions of the bootstrap procedure (raising oneself by the shoe laces), compiler first compiler and already with its participation is collecting all the rest. How to deal with this is not very clear, if only to compile on the device, but there it will take years. For the N800 mono, some hero was able to collect, but it refused to work on the n900, falling out with SIGSEGV. If anyone is interested in how this problem has been solved, or you can independently touch the mono on the device (you can write directly in Visual Studio, if that) I ask under the cat.
To begin, I will describe how to do it failed . However, experience was obtained and the information can be very useful.
I will not write about the SDK, about its installation and configuration, and without me much has been written.
')
Damn the first. Compile on the device.
- We bring /etc/apt/sources.list to the following form:
_ We remove from the links, it is there for the simple reason that the parser is a sucker, and does not even understand the code tag.deb http_s_://downloads.maemo.nokia.com/fremantle/ssu/apps/ ./
deb http_s_://downloads.maemo.nokia.com/fremantle/ssu/002 ./
deb http_s_://downloads.maemo.nokia.com/fremantle1.2/ovi/ ./
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
deb http_://repository.maemo.org/ fremantle/tools free non-free - Set build-essential, bison, gettext, m4
- ./configure && make && make install
- We realize that the process will take decades and look for other ways.
Damn the second. Compile on emulator.
First we need to pull out the uncut rootfs itself. There are 2 ways. First, you can unpack the flasher firmware (flasher-3.5 -u -F IMAGE) and mount rootfs.jffs. In fact, there are not jffs, but ubifs, by the way. I got here on this manual .
You can also load the recovery system, as described here . There, this image is used in order to move sections, but we do not need it. After that, in the internal console, we mount -t ubifs ubi: rootfs / mnt and merge everything onto a USB flash drive. A good backup method, by the way, is highly recommended.
Further on a manual we make to ourselves an image for qemu.
In order to make life easier for you and to be able to chroot into the armor environment, you will need the qemu-kvm-extras-static package. Copy after installing / usr / bin / qemu-arm-static to / bin your system and the chroot starts to work in a magical way. If anyone is interested in how this happens, they can read about binfmt_misc and other goodies that linux allows us. Theoretically, this can be done on the ubuntu x86 device itself in the chroot environment, and in it start the wine. Although, most likely it will not work, for we will come across all the same unsupported system calls.
We are assembling, creating the maemo directory, expanding the image that we have dumped, then everything is on the first pancake.
As a result, during the compilation, mcs began to crash with an internal error and I could not do anything about it. Nevertheless, the build environment was obtained independent of the scratchbox (which, among other things, is also only under i386 ).
Success at last!
On the third day, the Sharp-eyed Eye noticed that the shed had no wall. Namely: almost all mono is managed dll-ki, which absolutely all the same under which platform they are launched. As a result, the following plan matured:
- Through apt-src install, we pull out the raw mono. In this case, they are already laid out in packages so that they are then convenient to put.
- We scoff at the contents of the directory with debian build scripts so that all files are in / opt (on nokia and a very small rootfs, if someone is not up to date)
- We collect under amd64
- We collect platform-dependent binaries in the chroot-environment of Section 2 (errors again in the scratchbox, did not understand)
- We thoroughly mock the packages, changing these same binaries in them, ruling dependencies, inserting crutches
Actually, the fourth step was facilitated by the presence of the option --disable-mcs-build, which the uncle from Novell specifically invented for such cases. I will not describe the build process, this time (after 5 unsuccessful attempts!) Turned out to be quite trivial.
The bundles and versions of libraries in Maemo and Ubunt are somewhat different, so I had to pick them up. But it's worth it: I managed to transfer to the device the normal system scattered across the library packages (not fully yet, but I'm working on it) instead of the 260-meter tarball, which is generated by ./configure && make. Actually, now mono I have devoured about 27 meters / opt with the weight of packages at 12. At the same time, almost the entire .NET 2.0 is already available:
System.dll, System.ServiceProcess.dll, System.Drawing.Design.dll, System.Transactions.dll, mscorlib.dll, System.Drawing.dll, System.EnterpriseServices.dll, System.Web.dll, System.ComponentModel. DataAnnotations.dll, System.IdentityModel.dll, System.Web.DynamicData.dll, Mono.Data.SqliteClient.dll, System.Configuration.dll, System.IdentityModel.Selectors.dll, System.Web.Extensions.Design.dll, Mono.Data.Sqlite.dll, System.Configuration.Install.dll, System.Management.dll, System.Web.Extensions.dll, System.Core.dll, System.Messaging.dll, System.Web.Routing.dll, System.Data.DataSetExtensions.dll, System.Runtime.Serialization.dll, System.Web.Services.dll, Mono.Messaging.dll, System.Data.dll, System.Security.dll, System.Windows.Forms.dll, System.Data.Linq.dll, System.ServiceModel.dll, System.Xml.dll, Mono.Security.dll, System.Design.dll, System.ServiceModel.Web.dll, System.Xml.Linq.dll
You can install this miracle on your device by adding the following line to sources.list:
deb http_://archive.kebrum.com/n900/ all mainand installing the libmono-winforms2.0-cil package, which will pull everything else along. Unfortunately, I haven’t transferred any more packages for now, for it is already 4 am, but I will definitely take care of this later (I’ll transfer gtk software).
If someone wants to transfer their software to C # on the N900 using this assembly, please contact me to keep you informed.
And do not judge strictly for spelling with punctuation, night in the yard, eyes are red, I really want to sleep, and I barely get to the keys.
UPD: With the help of scrap and some kind of mother, GTK # was moved (not everything yet). Well, not such a piece of mono, necessary for the package mono-devel.
Source: https://habr.com/ru/post/116771/
All Articles