std::deque Won't Compile for Teensy 3.x

Status
Not open for further replies.
G

gfvalvo

Well-known member
Hi All. Really simple MRE here. Arduino / Teensyduino 1.8.15 / 1.54
Code: 
#include <Arduino.h>
#include <deque>

std::deque<uint8_t> myQueue;

void setup() {
  myQueue.push_back(100);
}

void loop() {
}

Error Message:
Code: 
d:/arduino-1.8.15/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
collect2.exe: error: ld returned 1 exit status
Error compiling for board Teensy 3.5.
It does compile for T4.x (and ESP32 / SAMD for that matter). But, I don't have a board to test it. Any suggestions?
Thanks.
 
Hi guys,

I have a partial answer to this issue.

firstly here is my setup...

teensy 3.6
visual studio 2019
visual studio v micro extension ( Arduino & teensy support in visual studio).

if I use release mode and compile it... it fails.

compile failure.jpg

if I use debug mode it compiles just fine.

compile sucess.jpg

This leaves me to believe that it's a linking problem possibly a link time optimisation, I also think that in debug mode ALL optimisation is turned off (please correct this if I am wrong). Additionally if I use any compile option that uses an LTO (Link time optimisation) option I get additional errors.

compile failure2.jpg

I hope this information is of help to somebody

best regards

Simon.M
 
Last edited:
I am seeing a similar issue (same error message) which I suspect may be related to yours. I'm just using the Arduino IDE, nothing fancy. See https://forum.pjrc.com/threads/68366-std-string-causes-link-error?p=290174#post290174. Unfortunately I don't have an answer for either of us at this time. I'm pretty sure this problem did not exist in some earlier version of Arduino or Teensyduino, because I successfully wrote some very similar code a year or two ago.
 
Last edited:
hi jwhoag,

If you look at the last image in my last post, from the way it reads. start from the very first line and it says "error linking for board teensy3.6". To me that means it compiled, but failed to put all the bits (main code + libraries) into one file. I am reasonably sure it's going be something like a compiler option that needs changing. This usually ends up being a command line option. Most of the IDE's that i have seen use a dos style command line compiler in the background.

The hard part is locating which of the command line option causes this issue.

This is just my opinion from limited information in the error messages seen in visual studio.

best regards

Simon.M
 
Simon.M said:
hi jwhoag,

If you look at the last image in my last post, from the way it reads. start from the very first line and it says "error linking for board teensy3.6". To me that means it compiled, but failed to put all the bits (main code + libraries) into one file. I am reasonably sure it's going be something like a compiler option that needs changing. This usually ends up being a command line option. Most of the IDE's that i have seen use a dos style command line compiler in the background.

The hard part is locating which of the command line option causes this issue.

This is just my opinion from limited information in the error messages seen in visual studio.

best regards

Simon.M
Click to expand...
It enough to just add a Serial.println() somewhere to the code. No commandline option can do that.
 
There is a weird linker issue which sometimes doesn't link in _write (which is defined in print.cpp). You can work around this by placing a dummy Serial.println("") into startup. There are some posts about this in the forum... Not nice but works.

Edit: ups, crosspost
 
Mcu32: Your idea crossed my mind before I even came to this forum. I added Serial.print("hi"); to my code, but the problem persisted so I discarded that idea. But once I read your comment I noticed your solution was to add Serial.println, so I tried that instead and found that yes, Serial.println does resolve the issue, but Serial.print does not. That could be an interesting clue if someone is looking into a proper resolution for this issue.

If I were to venture a guess at what the root problem is, I'd look to see if there might be some debug code somewhere that perhaps does not get completely optimized out unless the more stringent code removal algorithm ("Smallest Code") is selected. And for your solution, println apparently actually uses the _write_r function for whatever reason, so it's not marked for removal by the optimizer, and thus the errantly remaining debug code can link. Imagination space there for a moment.

Anyway, thanks guys, I now have two solutions that work!
--Jeff
 
Status
Not open for further replies.
Back
Top