Could somebody quickly check my code, it doesn't seem to print the value of f. Either I'm using nl_relocdata wrong, or then I'm too tired and am missing something silly.

http://pastebin.com/N2iiUhd1

That's more or less how SDL behaves at one point, and it's reallocating the function pointer that causes issues. The strings print out fine, calling the function doesn't work though.

EDIT: I've tried everything I can think of. Am I really missing something here or is there no way to use nl_relocdata on a pointer to a function? (I doubt it, even in the wiki it is mentioned)

I see. But how come then that you were able to see the strings?

It does work now, but I'm afraid it will make the porting process a rather "hacky" and dirty one, with #if directives everywhere (breaking the clean code and flexibility) as SDL does rely quite a lot on structs. The code is not that simple in SDL as in the example, so the result might be spaghetti code. For now I'll try to see how it goes with nl_relocdata, if the code becomes an ugly mess I'll tell you. Thanks anyway for pointing out that fix, it'll be useful.

What are the drawbacks of using the ELF loader?

I think I've finally--after many smashed walls, headaches and a bucket of aspirin--narrowed down one major issue.

Have this piece of code for instance:
#include <os.h>

typedef struct type1_t {
    const char *s;
} type1_t;

typedef struct type2_t {
    const char *s1;
    const char *s2;
} type2_t;

int main(void) {
    type1_t test1 = {"foobar"};
    type2_t test2 = {"foo", "bar"};
    printf("test1.s: %s\n", test1.s); /* Prints "foobar" */
    printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */
    printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */
    return 0;
}
As you can read, the output is:
test1.s: foobar
test2.s1:
test2.s2:
Which is completely wrong. Here's what the output obviously should be: http://codepad.org/DQcGIFy3

I think this might be one of those ARM struct alignment issues, or possibly some other bug. Either way, it has kept me from advancing with the port.
Any input on this one, ExtendeD? (or others, if you know what might be causing the problem)

Sure.

Edit: disregard that, got it to work.

hoffa, will you still continue to try the SDL port?

Yes, I will continue with the SDL port.

either the resulting binary cannot be sent to the calculator

What do you mean exactly?

Using nspire_emu, if I try to send the file nothing happens. No errors no nothing. Now that you mentioned the memcpy issue (didn't anyone was aware of it), I think it might very well be because of that.

or then that GCC doesn't compile the code (with some undefined reference's to memcpy).

See http://www.unsads.com/projects/nsptools/ticket/27 .
I'll quickly fix it if it's a blocking problem for you.

I'd appreciate it a lot if you could fix it, it would allow me to advance with the SDL port and with this library. I'm pretty sure it's what's causing the file not being sent.

A suggestion:

ngl_create_surface(ngl_uint w, ngl_uint h)

Should probably be

ngl_create_surface(ngl_uint x, ngl_uint y, ngl_uint w, ngl_uint h)

ngl_create_surface only allocates memory for the surface. The surface can then be blitted to another surface (which can then be copied to the framebuffer using ngl_flip) using ngl_blit_surface, which asks for the position (the ngl_rect dst_rect parameter).

Edit:
Added support for 16-level grayscale format.

NGL is a very lightweight graphics library that I've written that provides buffered access to the TI-Nspire's framebuffer. It provides only a few functions and is not supposed to be a full-fledged graphics library with every drawing routine available, it only includes the basic bricks required (i.e. drawing pixels, filling rectangles and drawing sprites). If it even means anything, I'd say I'm sticking to the SDL philosophy.

It is compatible with CX and non-CX calculators, although binaries are not interchangeable between the two, for flexibility- and speed-related reasons. You can find the "documentation" on the project's github, although the code should be self-documenting and not too difficult to grasp.

Github: https://github.com/Hoffa/NGL

I have one last issue to tackle/understand before I can provide a nice package of the library (and there are still a few bugs to hunt down and improvements to be made). How am I supposed to declare sprite data? ngl_load_image takes as input raw image data and then parses it, but the problem with defining the raw data array is that either the resulting binary cannot be sent to the calculator, or then that GCC doesn't compile the code (with some undefined reference's to memcpy). If I put the array in another translation unit (i.e. in some header or other file) the former happens. If I declare the array in main's scope, I get the memcpy issues. I see little logic in this, maybe the TI-Nspire doesn't like big chunks of statically allocated data (but GCC itself is a very good compressor). Once I manage to deal with that, drawing sprites would be no issue. Any help regarding that?

EDIT: on hold; working on the SDL port.

Output:
$ nspire-ld sdl.o libSDL.a
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(unwind-arm.o): In function `get_eit_entry':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:614: undefined reference to `__exidx_start'
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:614: undefined reference to `__exidx_end'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
collect2: ld returned 1 exit status
Seems like some ARM specific errors. Doesn't seem to recognize the entry point.