Thanks! Have you tested it? If it works with your projects, I think I'll replace the skeleton in the OP with it.

Hmm...perhaps I should break the libraries into separate files, so the user does not need to link everything into his program.
Then again, 33K is not very large considering the fact that the Nspire has 32 MB of flash. Even accounting for the OS, it's still over 20 MB.

I haven't a clue what syscalls.c is. It came with Ndless.

syscalls.c contains OS stubs requires by "newlib" (the implementation of stdlib integrated with YAGARTO).
The stdlib is not really required in our case, because most of the functions can be found in the TI-Nspire OS, you just need to define them in Ndless headers.
And it appears that newlib is built without -fpic in YAGARTO (pc-relative instructions), so the stdlib functions may crash.
The stdlib should only be enabled if the program uses floating-point arithmetic, similarly to the Ndless's particles demo.

Most programs should be built with the -nostdlib option for nspire-ld.

There has to be some way to have it not include the unused functions.  I am almost sure TIGCC/GCC4TI dose it.

Headers do not influence program size, the libraries does. The .a file should contain separate .o files (as it does). The granularity for inclusion is a .o file. So your problem is quite strange.

Could you try to build with the flag -nostdlib for nspire-ld? Could you check that the .tns doesn't contain series of zeros?
Could you try to run a "arm-none-eabi-objdump.exe -D <your_program.elf>" which disassemble the program, and see which symbols appear?

Did you change some files used for compiling? That seems a bit strange. I hope this doesn't mean data loss...

Yes, the .c file includeds <os.h>

Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.

What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all.  Here is the error I am getting:

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$ make clean;make
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c
nspire-ld main.o utils.o -nostdlib -o Trapped.elf
utils.o: In function `setlevel':
utils.c:(.text+0x28): undefined reference to `memset'
utils.c:(.text+0x1f8): undefined reference to `memset'
utils.o: In function `setladder':
utils.c:(.text+0x504): undefined reference to `memset'
utils.c:(.text+0x540): undefined reference to `memset'
utils.o: In function `drawlevel':
utils.c:(.text+0x8f0): undefined reference to `memcpy'
utils.c:(.text+0x904): undefined reference to `memcpy'
utils.c:(.text+0x918): undefined reference to `memcpy'
utils.c:(.text+0x92c): undefined reference to `memcpy'
utils.c:(.text+0x944): undefined reference to `memcpy'
utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow
collect2: ld returned 1 exit status
make: *** [Trapped.tns] Error 1

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$

The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.

Yes, the .c file includeds <os.h>

Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.

What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all.  Here is the error I am getting:

Code: [Select]

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$ make clean;make
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c
nspire-ld main.o utils.o -nostdlib -o Trapped.elf
utils.o: In function `setlevel':
utils.c:(.text+0x28): undefined reference to `memset'
utils.c:(.text+0x1f8): undefined reference to `memset'
utils.o: In function `setladder':
utils.c:(.text+0x504): undefined reference to `memset'
utils.c:(.text+0x540): undefined reference to `memset'
utils.o: In function `drawlevel':
utils.c:(.text+0x8f0): undefined reference to `memcpy'
utils.c:(.text+0x904): undefined reference to `memcpy'
utils.c:(.text+0x918): undefined reference to `memcpy'
utils.c:(.text+0x92c): undefined reference to `memcpy'
utils.c:(.text+0x944): undefined reference to `memcpy'
utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow
collect2: ld returned 1 exit status
make: *** [Trapped.tns] Error 1

Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$

The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.

Is this only a problem when you use the statically-linked library?

gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).

In the next release of Ndless, OS calls will be defined as static inline functions. I'm not sure how GCC will react in this case.