The Embedded Template Library provides the data structures of the STL without using dynamic allocation, to be used in embedded development.
I'm experimenting with the ATSAMD21 in Atmel Studio, and cannot use dynamic allocation. Therefore I tried the ETL, but it gives me the same errors I get when I'm trying to use STL:
Error ld returned 1 exit status
Error undefined reference to `_exit'
Error undefined reference to `_close'
Error undefined reference to `_fstat'
Error undefined reference to `_isatty'
Error undefined reference to `_lseek'
Error undefined reference to `_read'
Error undefined reference to `_sbrk'
Error undefined reference to `_kill'
Error undefined reference to `_getpid'
Error undefined reference to `_write'
As far as I know, these errors mean that a wrong target architecture was selected for the compiler. However, that shouldn't be the case, because my program worked just fine before I defined a single ETL structure. Also, the ETL is composed of just a bunch of header files.
My guess was that ETL uses code from STL, and the gnu compiler included in Atmel Studio can't handle it. (but they why did they even include STL if it's completely unusable?)
However, ETL can supposedly be used even without STL.
So I defined #define ETL_NO_STL in my project, but I still get the same errors.
new
It seems to be working correctly in "release" mode, these errors only appear in "debug".
The differences between debug and release don't indicate me any use of STL in one, versus the other:
Debug:
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-g++.exe" -mthumb -D__SAMD21J18A__ -DDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\SAMD21_DFP\1.2.276\samd21a\include" -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\arm\CMSIS\4.2.0\CMSIS\Include" -O1 -ffunction-sections -fno-rtti -fno-exceptions -mlong-calls -g3 -Wall -mcpu=cortex-m0plus -c -MD -MP -MF "main.d" -MT"main.d" -MT"main.o" -o "main.o" ".././main.cpp"
Release:
"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-g++.exe" -mthumb -D__SAMD21J18A__ -DNDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\SAMD21_DFP\1.2.276\samd21a\include" -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\arm\CMSIS\4.2.0\CMSIS\Include" -O1 -ffunction-sections -fno-rtti -fno-exceptions -mlong-calls -Wall -mcpu=cortex-m0plus -c -MD -MP -MF "main.d" -MT"main.d" -MT"main.o" -o "main.o" ".././main.cpp"
The only other difference is that the debug build has an extra line: Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
The debugging level is not the cause. Setting it to g3, g2, g1, or turning it off doesn't change anything. The difference is whether NDEBUG is there in the command. Maybe without it there are some unnecessarily POSIX consistency checks performed?
A compromise solution can be to add the NDEBUG parameter in debug mode, while still specifying a debugging level (like -g2 or -g3)
This allows to use breakpoints and to watch the values of variables in a debugging session, the only downside seems to be that assert statements won't work, a feature much less often used in embedded development compared to other platforms.