Where you want to compile it in scratchbox or on the device? When you want to do it on the device you should use a chroot not directly install to the device.

I would recommend to compile it with gcc4.2 first. I think this gcc4.6 broken my dev environment, but I need to check.
I will try also to build 3.5.9 again because of the assembler messages these are not correct and I think it happens because I tried so many things. So next days I am starting from scratch again.

It seems gcc4.2 is not in my reopos, only gcc.4.2-base, which is a completely empty dummy package that doesn't depend on anything either...
There's no actual gcc-4.2 package.
There is gcc-4.6 however.

My sources look like this:

Code:

# cat /etc/apt/sources.list.d/hildon-application-manager.list 
deb http://repository.maemo.org/community-testing/ fremantle free non-free
deb http://repository.maemo.org/extras/ fremantle-1.3 free non-free
deb http://maemo.merlin1991.at/cssu/community-thumb/ fremantle free non-free
deb https://maemo.openrepos.net/halftux personal main
deb http://maemo.muarf.org/apt-mirror/mirror/downloads.maemo.nokia.com/fremantle/ssu/apps/  ./ 
deb http://maemo.muarf.org/apt-mirror/mirror/downloads.maemo.nokia.com/fremantle/ssu/mr0  ./ 
deb http://repository.maemo.org/extras-testing/ fremantle free non-free

Am I missing something?

There are to methods to compile something for the N900.

1. compiling in cross environment
2. compiling on device

When you use the offical cross environment you don't need to set these cflags and have gcc installed. When you are able to build your own cross environment, then probably I can' teach you anything new, but then take care of these cflags.
If you have lots of floating point operation you could change mfp to neon for example. So the normal vfp is in armv7 VFPv3 which can be implemented with either 32 or 16 doubleword registers. Support for these flags depend on the compiler different compiler, different flags, different support, different bugs. Before armv8 for neon is the IEEE 754 standard not fully implemented. Therefore for example when you use gcc4.6 you also need to specify -funsafe-math-optimizations to activate neon. But the most important bit is to use -mfloat-abi=softfp, because all binaries from N900 are compiled with that and you can't mix different modes of hard or soft fp binaries.

When you want to compile on device I would suggest not doing it on a daily driver. So there is a sdk repository you could add. But this is somehow dangerous because it can fill up your root.

Thats why a chroot environment on the device itself is much more safer. It is also easier to try something and when it is not working or the build environment is broken, you could easily delete it and take an old backup from it to start again or have different chroot on device for "quick" testing different gcc's or other libraries.

I don't have so much experience for on device development and still need something to figure out.
Because the method which is known and which I also use, is to take the rootfs from the sdk, but I think the rootfs is made for qemu emulation and it could be that there is a difference compared to real device.

Hence for python 3.5.9 compiling in qemu scratchbox I don't get the assembler messages but on the device I get them.

gcc-4.6 is somehow special, in my opinion you can't use this gcc4.6 package from extras in scratchbox. For on device development it should be possible, but I would try first gcc-4.2.

So if somebody has a perfect setup for a chroot, it would be nice to share it.

^ yes but gcc-4.2 does not show up at all, e.g. with


I was thinking to just 'make' on device, not 'make install'.
No chroot.
You still advise against it?

As I stated above you need to add the sdk repository, and after an apt-get update, apt-cache will find it. And then you can install the packages. But make a backup first. When you have installed many application to your N900 it could be that you fill up your rootfs (because the sdk repository is not optified for the device partition structure) and it could be that the phone doesn't boot anymore.

But my studies are not over and you are on a cssu-thumb system which was made with gcc linaro-4.7 and I don't know how it harmonize. Best would be to have a second device on stock and install gcc-4.2 and make your first try to study and learning. After that you could make further experiments.
For thumb I would use the scratchbox environment.

Here to make it more clear what you need to add. The tools repository is maybe not needed.

Here are the used cflags in scratchbox for gcc-4.2:
-march=armv7a -mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=softfp -fno-omit-frame-pointer -fno-optimize-sibling-calls

For the linker:
-rpath-link /usr/local/lib -L/usr/local/lib -rpath-link /lib -L/lib -rpath-link /usr/lib -L/usr/lib

deb options:
DEB_BUILD_OPTIONS=maemo-launcher,thumb,vfp

Cross your fingers, good luck!

Some progress made, new chroot dev from scratch with gcc-4.6 and the compiling looks promissing. Now I will let run the 398 test on the device and will see. Maybe tomorrow I will have a compiled new package with a working python.

The package which I already released is broken, sorry for that, hopefully I can release a working one.

It's definitely doable.

A few years ago I stopped relying on the community repos and just started building stuff from source.

I went for the LibreSSL fork of OpenSSL, and I have it installed side-by-side with the old OpenSSL version Maemp has installed, since their .so names don't conflict (0.9.8 is installed at .so.0, while the more recent libressl or openssl with version 1.x.y installs at .so.1).

Building LibreSSL from source was great because it basically has no dependencies. Self-contained, very easy-for-a-newb-like-me build. I imagine OpenSSL is just as nice.

Note that this won't just help upgrade all the other components "for free" - since they are different major version numbers with separate .so names things have to be recompiled against the new ones. (So for example I have latest `ssh` and `curl` and Python that I built using the latest libressl, but for example the old 2.5 and 2.7 Pythons from the repo still use the old 0.9.8 OpenSSL.)

Python 3.6 (latest at the time I last built Python from source) had a lot of dependencies. Since by then I was ignoring the repos for anything I built myself, I didn't bother checking how many I could already get for free, and just built everything that was needed to make it compile (or wasn't needed but seemed quick and easy, like latest `zlib`).

I built everything directly on my N900 at the time, so my experience is probably not very helpful for trying to build it in scratchbox or whatever.

I really ought to get a cross-compiling arrangement going, but that's just enough of a pain and investment that I haven't mustered up the drive to do it. Looking around here I see people have made strides to make the Scratchbox environment more conveniently accessible so maybe I'll use that. (But honestly I like building things on my N900, though the multi-hour compiles for things like nodejs aren't fun, and I never did get to gcc 5.0.0 because the compile would crash the N900 after a solid day of compiling even with tricks like a massive SD card for pure swap space and ionice+nice and disabling the watchdogs to get it from choking itself, hence me finally accepting that I need to embrace cross-compiling, if only to get the latest compilers on the N900 to keep the perversion going.)

Anywau in the meantime I have tarballs of everything I built, and if someone suggests a way to share them that feels low-effort enough to me I'm happy to dump them somewhere.

I can also share the `./configure` arguments I used just because those are always a good tedious 15 minutes to read through and decide.

And if you want I can check for any other steps outside the usual

1. unpack source
2. ./configure
3. make
4. sudo make install

workflow that I used if anyone wants, but for the most part it was that very regular workflow without weirdness, besides the standard Maemo 5 weirdness like prefixing half the install paths with `/opt/maemo`.

Very nice offer from you! I sure hope someone who has online storage or something could contact you. Making everything with N900 is something I really like as a manner. I myself do not know anything about compiling but it is something I would someday like to learn. I am an end user. What I can contribute to the community is cheering and supporting words when someone like you has done something and offers to share it.

And you have really tried - that sdcard swap watchdog etc . made me smile. Like "I WAN'T THIS TO WORK!!!" attitude.

Have you already tried Maemo Leste?

Appreciated. I can think of several ways of doing this.
I have NO experience with creating Debian packages, which, afaiu, would be required to upload the software to maemo.org/packages or similar location (it's all a labyrinth to me).
PM sent.

Very much appreciated, please integrate as much documentation as possible into your tarballs!