Arduino.CC 1.6.8 IDE — Arduino Zero / RedBear Duo Conflict

With Arduino.CC IDE 1.6.8 and Arduino SAMD Boards 1.6.4 and RedBear Duo 0.2.7 installed, when compiling against the Arduino Zero, compilation fails and mentions the RedBear Duo as culprit.

In file included from /Users/ReiVilo/Library/Arduino15/packages/arduino/hardware/samd/1.6.4/cores/arduino/Arduino.h:40:0,
from /var/folders/hz/wncgspfd5wxgzmly78yvzk_m0000gn/T/build150dbfda2222d62025a1934a4f9f0b3c.tmp/sketch/sketch_apr04a.ino.cpp:1:
/Users/ReiVilo/Library/Arduino15/packages/arduino/hardware/samd/1.6.4/cores/arduino/itoa.h:29:65: error: conflicting declaration of C function 'char* utoa(long unsigned int, char*, int)'
extern char* utoa( unsigned long value, char string, int radix ) ;
In file included from /Users/ReiVilo/Library/Arduino15/packages/RedBear/tools/arm-none-eabi-gcc/4.9-2015-q3/arm-none-eabi/include/stdlib.h:11:0,
from /Users/ReiVilo/Library/Arduino15/packages/arduino/hardware/samd/1.6.4/cores/arduino/Arduino.h:25,
from /var/folders/hz/wncgspfd5wxgzmly78yvzk_m0000gn/T/build150dbfda2222d62025a1934a4f9f0b3c.tmp/sketch/sketch_apr04a.ino.cpp:1:
/Users/ReiVilo/Library/Arduino15/packages/RedBear/tools/arm-none-eabi-gcc/4.9-2015-q3/arm-none-eabi/include/stdlib.h:184:8: note: previous declaration 'char
utoa(unsigned int, char*, int)'
char * _EXFUN(utoa,(unsigned, char *, int));

This issue has been posted at the RedBear Duo Forum also.

I just tried with the same setup except Arduino SAMD Boards 1.6.5 and this sketch:

void setup() {
  char x[5];
  unsigned int y = 1234;
  utoa(y, x, 10);
void loop() {}

And it compiles without error. Does that sketch cause the error for you?

Thank you for your suggestion.

Unfortunately, the basic sketch fails to compile —see the attached screen-shot.

Surprisingly, the IDE uses the tool-chain from RedBear…


…instead of the tool-chain from Arduino.


Thank you for your suggestion.

Well it wasn't a suggestion, it's just that I think I know the solution but I can't test it if I can't reproduce the error. I can't figure out why we're getting different results. I've ran into this problem before while helping someone get a different 3rd party hardware package working: Installing contributed board package breaks other boards packages · Issue #4593 · arduino/Arduino · GitHub. I believe the issue is that since both tools have the same name, arm-none-eabi-gcc, the Arduino IDE gets confused so RedBearLabs needs to change the name, as Elector did. This is something the Arduino IDE should be able to handle correctly but the issue hasn't gotten any attention from the developers, maybe because the cause of the issue was unknown when initially reported. So if you want to to try this out you can do the following:

Change /Users/ReiVilo/Library/Arduino15/packages/RedBear/tools/arm-none-eabi-gcc to /Users/ReiVilo/Library/Arduino15/packages/RedBear/tools/arm-none-eabi-gcc-redbear

Change /Users/ReiVilo/Library/Arduino15/packages/RedBear/hardware/STM32F2/0.2.7/platform.txt line 8 from




Unfortunately I'm working blind here so let me know how it goes. Per

The trip fixed the issue.

However, the ~/Library/Arduino15/packages folder contains 7 folders named arm-none-eabi-gcc


- ```


- ```


- ```


All those non-Arduino platforms of to the right `arm-none-eabi-gcc`. Why shouldn't Arduino?

Issue [#4593]( has been closed despite not having been fixed.

The trip fixed the issue.

Glad I was able to help. This issue should be fixed in the ReadBear duo hardware package so that others don't encounter the same problem you did.

All those non-Arduino platforms of to the right arm-none-eabi-gcc. Why shouldn't Arduino?

Do you mean why doesn't the same issue occur with those packages? I think it's because those others don't have the conflicting definition of utoa(). I didn't find Simblee but all the rest except RedBear are using arm-none-eabi-gcc 4.8.3, RedBear is 4.9-2015-q3. This might be relevant: Conflicting type for first argument of utoa with stdlib.h declaration · Issue #4002 · arduino/Arduino · GitHub.

Issue #4593 has been closed despite not having been fixed.

No, it's still open. ElectorLabs closed it after we fixed their package but I requested that they reopen it because I think the IDE should be able to handle different packages using the same tool name and there was one other problem exposed in that issue.