I've recently dusted off my N800 which had been sitting idle for several years. I want to write a new program for it, but having recently learned C++11, I don't want to have to work with the older C++ standard if I can avoid it.

So I've packaged up a GCC 4.9 (and modern binutils) cross compiler toolchain.

If anyone else is interested in this, you can grab the diablo-gcc-4.9 package from http://www.users.on.net/~toojays/mae...opment/wheezy/. It's compiled for Debian 7 / amd64, so should work on Ubuntu systems as well. The source package is there as well, so can be easily rebuilt for other Debian-based systems if needed.

More details (copied from the README.Debian which is installed by the package):

This package contains updated C and C++ cross-compilers for Maemo 4.1
(Diablo). These install under /opt/diablo-gcc-4.9. They are configured for
maximum compatibility with the original Diablo toolchain.

The intent is that binaries produced using this toolchain can be installed on a
Diablo system with no additional dependencies. This is largely achieved by
replacing libgcc_s.so and libstdc++.so with linker scripts which cause the
desired symbols to be looked for first in the original (i.e. GCC 3.4) versions
of those libraries. If the desired symbols are not found there, they are linked
statically.

The debug version of libstdc++.so does not use the same linker script trick,
since it seemed like that would be more confusing than useful. If you want to
link against this library, add "-L
/opt/diablo-gcc-4.9/arm-none-linux-gnueabi/lib/debug/" to your g++ link command
line, and ensure that library is accessible when running the compiled program.

There are some ABI compatibility corner cases (see
<http://gcc.gnu.org/wiki/Cxx11AbiCompatibility>) to be aware of if mixing
objects compiled for C++11 and C++98, but most things should just work. I was
able to build a simple gtkmm application using C++11, and run it against the
gtkmm libraries from diablo extras with no problem.

Thank you, would you be interested in making classic gcc-4.9 package similiar to this one?

I think that LTO optimalization made in 4.9 could be also very useful for N900

At this moment I've been able to test it only on x86_64, where it saved about 5-20% of binary size.

hello, i'm pretty new to maemo and cross-compiling for it, and i can't figure out how to use this toolchain

i added /opt/diablo-gcc-4.9/bin and /opt/diablo-gcc-4.9/arm-none-linux-gnueabi/bin to my $PATH, but when i try compiling i get

do i have to link by hand everything? am i missing something?

it just occurred to me...
considering the wiki for n8x0 and scratch is outdated, instructions don't work properly anymore ...etc. and even when they did it was a royal pain.
Could someone tinker with the wiki there and amend it to date so it isn't a hairpulling experience ?...Instead of the scratchbox attemptee ending in a pavement stain from ledge-jumping from 37 stories ....
I mean..hell...I like puzzles... I like challenges...but...I don't enjoy going near the mess anymore...
hrm...
anyway..
just a thought...
but considering the op has managed a new toolchain that can be used with debian 7 amd64...
for absolute simplicity ..
for new and old members alike..
would it be possible to create a debian 7 distro which has scratch already plumbed ready for n8x0's ..n900 even?
Is it reasonably feasible?....
is it far far too much work for it to be rationally doable? ..
is it impossible? (since I have not undertaken such a feat I would not know...)
I do know they had a knoppix distro way back in the day ...fire it up away you went...I'm not sure if they had a whole team working on it nor how long it took.

I think you are the first user of toolchain besides me, and so this is the first bug report. I reckon it will work for you if you make the following changes to the linker script:

I didn't need this at the time I was using this compiler because I was using it within a chroot.

Let me know if this helps.

It's probably possible, but in terms of the amount of time required in relation to the payoff, most of us are better off just running scratchbox in an old distro on a VM. E.g.
Silvio's vagrant setup worked for me last time I dabbled with N900 development.

I have tried a few times to come up with a new development environment which doesn't require scratchbox. Typically using a chroot with the N800/N900 rootstrap, using qemu, and patching in native amd64 binaries for things where extra performance is needed (e.g. compiler, gzip, etc). Following similar principles as described at https://mariusv.wordpress.com/2008/1...a-pot-of-gold/ , but without scratchbox at all. I never managed to get as far as bringing up X in such an environment. The scripts which start the GUI on maemo have special code which causes it to behave differently under scratchbox which lets this work. IIRC, they do something different not just with X, but also with dbus, which I never unraveled. Additionally, on modern Debian, the Xephyr display server isn't compatible with maemo's X libraries.

If I were to start building a development environment for maemo today, I'd forget about emulation, and just focus on cross-compiling. Obviously I have already taken a step in that direction. The trouble is, once you go down this road, it becomes impossible to take advantage of existing (unchanged) development packages from the maemo repositories, because many of them were built with scratchbox in mind. IIRC, the Qt moc is one example of this.

Continuing on this thought, suppose we had a cross compiler, and corresponding library development packages for a GUI toolkit (I like gtkmm on Diablo, qt on Fremantle). Using the same versions and build flags as used by the real maemo libs, so anything built with this toolchain could be installed on maemo with no additional dependencies.

Hmm, I reckon you'd also want a way to create Diablo/Fremantle compatible debs, which would be another challenge.

Would that make life easier for anyone here? Or just add another confusing development option?

yea I understand the compat issue with Xephyr ...
and boy o ...that is really really too bad the scratchbox-less build enviro was brick-walled. Hm...

And...when you said .."Continuing on this thought, suppose we had a cross compiler, and corresponding library development packages for a GUI toolkit (I like gtkmm on Diablo, qt on Fremantle). Using the same versions and build flags as used by the real maemo libs, so anything built with this toolchain could be installed on maemo with no additional dependencies...."
Hell I'm partial to that ..

and lastly ..."Hmm, I reckon you'd also want a way to create Diablo/Fremantle compatible debs, which would be another challenge."
yea ... hm..well for the time being at least..considering that fremantle has plenty of hands in the pot over all the n900debian, fptf, etc...I think there are enough brains pointed at those probs without adding to them immediately...not to mention..there aren't alot of current brains focusing on the n8x0 line...fact is...for a long time there hasn't been....the last couple months it's been pretty much just you and Kotczarny that have been doing the pioneering for the n8x0.
in the long haul it would be advantageous to have 1 cohesive method across platforms..but right now with all the n900 projects going on I think ..it better to wait on that idea. But for goodness sake don't you dare stop on the n8x0's!

Scratchbox still works great on Gentoo and is easy to setup. Getting Gentoo itself installed will be your biggest hurdle as it doesn't have an installer. But the process is just like installing Maemo on an SD card, typing a bunch of commands.

I think I was misunderstood here. I didn't mean making a single package that would run on both Diablo and Fremantle. I was just talking about being able to build a deb on a modern system which will install on those older distros. I suspect that requires forward-porting the older dpkg toolchain. Might be simpler to just use an etch chroot for that part. I've never looked into that area, maybe it's a non-issue. I notice dpkg has a --deb-format option, perhaps that's enough?

ah...here I was thinking ..that you were thinking.. of a single package ...which seems to me to be quite a (if not well nigh an impossible) task...