Great progress! 

Indeed, very nice

I've tried porting some very small SDL programs and it works well. Haven't tried porting anything bigger yet though.

As far as the libs are concerned, most of the libs there seem portable. SDL_image for instance certainly is, and it's on my todo list.

what do you mean with performance? faster? or less usage of the processor for the same executions?

how much better does it perform now?

What doesn't make any sense is the size improvement induced by -O3 compared to -Os.

Booyakasha!

0.1.4's up. It should actually be 0.1.3b or 0.1.3.0.0.0.1 as it contains very little code changes, but hey, who wants to stay in 0.1.* forever? I'll probably jump to 0.2.0 once I get the mouse to work, just for shits'n'giggles.

Anyway, basically this version goes hand in hand with the new how-to guide. First of all I hid that whole NSP_COLOR_LCD thing from the user as it complicates the build process and whatnot. Then I added a very easily adaptable Makefile.sample file to the final archive which simplifies the build a lot (only a make cx/tc is needed to build now, no more cryptic commands). Also I added a primitive README file to the said archive; it doesn't really help anything at all (who reads README's anyway?) but it makes it look more serious. Then I did some general housekeeping to the code and removed some mouse-related test stuff clogging up the event loop. Oh and as I mentioned a few sentences earlier, I updated the how-to guide.

There won't be any updates for at least a few days as this version has been clinically proven through rigorous scientific experiments to be a "stable beta".

Have fun.

EDIT: Added images of the available fonts.

SDL is written in C, but works with C++ natively

So yes, but then again we need to get C++ to work (tangrs was working on it IIRC). So once there's C++, there's SDL C++.

Indeed it's a rather strange problem. I tried removing all code from SDL_Init() and just returning 0, but it still gives the mentioned error, whether it is called before or after the sqrt() function. However, what I noticed was that it works with no issues when using functions that do not return floating point types, such as ceil(). I'm not sure why it works without the SDL_Init() and doesn't if it is there (in one case the whole SDL lib is linked, in the other not; might have something to do with that), but it might be a Newlib issue, as the Hackspire wiki suggests:

Compatibility of Ndless with Newlib has not been tested. You may get definition conflicts and crashes due to Newlib running without the required relocation that Ndless doesn't provide. You should always build your programs with the nspire-ld flag -nostdlib, except if you need the single precision floating-point helper functions internally called by GCC when required (__aeabi_fadd, ...).