Though so - just after I got the post saying "it's not possible" I managed to link in the standard C library! For some reason doing a -lc didn't work and I had to specify the whole path (devkitgp2x\lib etc...) to the libc library
Do you know how you go about setting the area of memory used by malloc? At the moment I can call sprintf, but calling malloc(123) just hangs the 940. I presume there is some kind of function to call like malloc_set_area(0x00100000,0x01000000); (if the 940 is based at 0x02000000) or something? But what is the name of this function?
Download this:
http://www.gigasize.com/get.php/43308/arm-20060802a.zip
And there are examples in there (As well as a compiler to build them), I am pretty sure I have a malloc example in there (or perhaps every one of them does a malloc and then prints hello world first). Near the top of syscalls.c the base address of the heap is hardcoded, change it to whatever you like (this is in the 940 address space).
Trying to use a C library that is setup to build for linux or some other such platform may not work for a non-os platform. So if you are trying to use the same C compiler you use on the 920 you may fail. I am not that familiar with the inner workings of uclibc nor glibc so I dont know how to target those at a platform, and/or what files to seek out and destroy (in the compiler directory). newlib is easy, even if you take devkitadv or perhaps winarm or others that I think use newlib, and have left them targeted to who knows what, I think you can supply a syscalls.o, and of course -nostartfiles allows you to use your own crt0.o startup code.
For my gcc compiler above I have ripped out the guts of syscalls.c. There is just enough there to malloc, and printf. Printf calls a user supplied function that gets one byte/character at a time. I have examples that send that text to the display and examples that send it to the uart.
BTW I have started using -Ic:\arm\arm-thumb-elf-include on the gcc command line. I guess all these years I have been relying on files the compiler finds in the mingw directory. Better to dance with the one that brung you than someone elses include files. (I dont know if the above has it setup that way in the makefiles)
I use printf and sprintf often (for debugging) as well as memset, memcpy (for day to day use), etc. No problems there. Well, on the GBA or other ROM based platforms (or the GP2X if you are doing a bootloader I assume), you have to be careful where the format string is stored if it is in .data instead of .text make sure that crt0 initializes .data and .bss. For the 940 the only thing you have to worry about is remembering the physical 940 address is not the systems (920) physical address. Oh wait, you should look for the memcpy thread around here somewhere. Within minutes of trying I found at least 4 memset and memcpy implementations (winarm, mine, gph, ? ). One was byte based, very slow, and at least one did 16 bytes per transfer, which is about as good as you are going to get. So make sure you disassemble memset and memcpy no matter whos compiler/library you use to make sure they are using four register ldm/stm pairs. this will literally define success or failure. Another note, I have been using -O3 with gcc for years and not had problems. Not to say there should be, but other compilers will fall apart once you start to optimize. If you are not that brave go with -O2 at least, here again you dont want to throw away performance.
The floating point math libraries are compiled in (soft float) to my gcc build, if you really need them. you get that typical library complaint that no web page seems to have a good answer for. I figured it out one day and I think it is as simple as -nointerwork or some such thing, of course I wrote the answer on the back of an envelope and the envelope is long gone...There was no magic to it at all, no re-writing code or anything just a single command line switch in gcc...As far as that goes I kept gcc and newlib almost untouched, thumb might even work but it just serves to slow you down on this platform so dont bother...