I'm using XP and Arduino 1.6.12.
I had this error the other day compiling a sketch for Uno.
I found that if I changed the board from Uno to Mega my sketch compiled error-free. Then after changing back to Uno (which is the board I am using) it continued to compile OK.
rishrsoni:
Hello Eveyone,
I was facing the same problem with while compiling example code given alongwith the Utouch library of Henning Karlsen. I ran 1.6.3 Arduino with compatibility of Windows98/WindowsME and suprisingly it complied smoothly. Hope it eases the trouble faced by you all !P.S : Running Windows XP SP2
Yes, Yes, Yes !!!! The problem arises from LOCALE the XP it treats. Just run Arduino in old compatibility mode and all scripts compiledand linked slower BUT WITH NO Problems!
Tested on current Arduino IDE 1.6.13!
Vink01:
Yes, Yes, Yes !!!! The problem arises from LOCALE the XP it treats. Just run Arduino in old compatibility mode and all scripts compiledand linked slower BUT WITH NO Problems!Tested on current Arduino IDE 1.6.13!
Thanks for the sharing what worked for you Vink01. I remembered seeing that solution to this problem but couldn't find it later. I don't have XP but frequently am trying to help people with this problem so I'd like to have some specific instructions to share. Is this correct:
Finally I found a working solution!
History: I have Windows XP with arduino version 1.6.12. I had the error when I tried to use sprintf() (- could resolve it by making one parameter global), I had it even with a simple Blink-sketch (- solution there: filling in some dummy global variables).
When I tried to replace ld.exe with the version from 1.0.5 I got the "unrecognized option '-plugin'" error. No option.
With LiquidCrystal_I2C the problem became so annoying I had to find a remedy!
Solution: download & install version 1.7.11 from arduino.org.
Even my most resistive sketches now compile pleasingly.
Hope you can confirm this finding.
how i solved my problem is
I closed my scetch,
run a new blank sketch (not the one you were coding) by clicking main Arduino IDE icon on my desktop.
then it worked fine !!! 
if I try to open my sketch, it keep giving error.
just run a new skecth.
12/02/16
I have run into a problem.
I am running an Arduino Mega which has some 260kbtes of ram.
I am working on screen programs using a TFT 2.8 and for the most part, I'm doing OK.
I plan on running multiple screens and intend to call them when needed and feed them with data as needed to each screen.
The problem I'm having involves the compiler. When the program goes above about 10,422 kbytes, the compiler refuses to compile the program and says that it cannot compile for board Arduino/Genuino Mega or Mega 2560.
If I commit out previously checked and run functions or their calls, I can get the program to compile.
Compiler report: Successful
Sketch uses 10,422 bytes (4%) of program storage space. Maximum is 253,952 bytes.
Global variables use 419 bytes (5%) of dynamic memory, leaving 7,773 bytes for local variables. Maximum is 8,192 bytes.
If I put some of the calls back in, the compiler fails.
Compiler report: Failed
collect2.exe: error: ld returned 5 exit status
exit status 1
Error compiling for board Arduino/Genuino Mega or Mega 2560.
The only difference in the two compiler runs was that I put back in some of the calls for code that I had committed out to make the compiler run.
The calls I put back in was good code I have previously checked and ran. Another screen.
Is there any way we can change to compiler to allow it to compile a larger program???
I spent some time this evening reading the post listed recently.
I to am running XP SP3. and Arduino 1.6.13.
I did turn on the verbose error message option, I also changed to compatibility to Windows 98. No help.
One of the last postings I saw talked about shutting down Arduino, opening a new (Blank) sketch and compiling it.
Once I did that, I was able to compile and upload the program to my Arduino Mega ONCE. .
The compiler came back with the following report:
Sketch uses 10,530 bytes (4%) of program storage space. Maximum is 253,952 bytes.
Global variables use 437 bytes (5%) of dynamic memory, leaving 7,755 bytes for local variables. Maximum is 8,192 bytes.
When I tried to recompile the program while changing nothing, the compiler failed and reported the following again:
Compiler report: Failed
collect2.exe: error: ld returned 5 exit status
exit status 1
Error compiling for board Arduino/Genuino Mega or Mega 2560.
Before I get this project completed, my program is going to get a LOT bigger. That is why I am using a MEGA.
Arduino, I think we have a problem here..
Ken
Hi,
Try an earlier version of the IDE...
You can have more than one version of the IDE on your computer at once.
A lot has changed OS wise since XP, so keeping legacy performance is probably getting very difficult for the IDE writers.
Tom....
KenK:
Arduino, I think we have a problem here..
Have you tried the compatibility mode solution?
If that didn't work have you tried the replacing the version of ld.exe included with Arduino IDE 1.6.13 with the version included with Arduino IDE 1.0.6?
I did change the compatibility mode to Windows 98. I am not sure it fixed the problem due to the intermittent nature of the problem.
I did find that if I shutdown IDE load and compile an empty program, compile it, shut the empty program down and reload my program, IDE will work for a while. Again, how long is random.
Windows 2000 might be a better option I'm not sure.
I have read that an older version of IDE might work.
I am going to try that. I assume the older versions of IDE are available on the cci website??
I do have a computer running Windows 7 but I don't like it (it's a laptop). I may try that one to see if things get better.
Ken
KenK:
I did change the compatibility mode to Windows 98. I am not sure it fixed the problem due to the intermittent nature of the problem.
That's precisely the issue Ken. I've thought I had this problem fixed several times only to have it eventually turn up again.
I had been running very successfully for a few weeks with compat mode for windows 2000 set for both the Arduino IDE as well as the loader (\arduino-1.6.12\hardware\tools\avr\avr\bin\ld.exe). BTW. I can't use win98 compat mode with the IDE, as it wont run at all.
Then today I started a new short sketch and that error returned. So I thought it a good time experiment and changed the compat mode of ld.exe to Windows98. That fixed the issue straight up and I thought yeah!
Then 5 minutes later I went back to a previous sketch (unmodified) that been working perfectly before, and suddenly it started playing up with the bug. So I changed ld.exe back to Win2k compat mode and it's back to working again.
So in summary, yeah this error is so random it's nearly impossible to know whether a change in settings has actually cured it or just made it latent.
Thanks for the update on the compatibility mode approach stuart10. It sounds like that's not a solution.
KenK:
I have read that an older version of IDE might work.
Arduino 1.0.6 should work with Windows XP. You can download it at https://www.arduino.cc/en/Main/OldSoftwareReleases. If you decide to try the solution of replacing ld.exe please do report on whether that worked for you.
IDE 1.6.9 here and so far I add a few variable declarations that get compiled out when I pass whatever boundary sets the thing off. It works.
GoForSmoke:
IDE 1.6.9 here and so far I add a few variable declarations that get compiled out when I pass whatever boundary sets the thing off. It works.
Yes, that sounds exactly the same as 1.6.12. Minor changes to the code can make the bug come and go, so even just adding a few unused global variables can solve the problem in the short time and let it compile.
pert:
Arduino 1.0.6 should work with Windows XP. You can download it at https://www.arduino.cc/en/Main/OldSoftwareReleases. If you decide to try the solution of replacing ld.exe please do report on whether that worked for you.
Yes 1.0.6 is definitely free of this bug. Unfortunately however it is missing some features compared to the later versions, and in particular cannot handle assembler ".S" files.
In a recent post someone mentioned that they tried a specific new version, 1.7.11, and it didn't appear to have the bug. I'm not sure if this was a nightly built or something, but I downloaded it (from the link given in the post) and when I get time I will test that out. I did try another "nightly build" a few weeks ago (not even sure of the version) and it wouldn't even open on my computer.
stuart0:
Yes, that sounds exactly the same as 1.6.12. Minor changes
In a recent post someone mentioned that they tried a specific new version, 1.7.11, and it didn't appear to have the bug.
Well that was a disappointment. It turns out ver 1.7.1.1 is a retrograde step and doesn't support assembler ".S" files. So I didn't get to test if it has the ld.exe bug, because I dumped it straight away.
1.7.11 is the arduino.org IDE. A while back there was an internal dispute in the Arduino company that caused a split of the members. The manufacturing arm created their own website, arduino.org and their own version of the Arduino IDE. Even though their version has a higher number, it has been much less actively developed than the arduino.cc IDE.
pert:
1.7.11 is the arduino.org IDE. A while back there was an internal dispute in the Arduino company that caused a split of the members. The manufacturing arm created their own website, arduino.org and their own version of the Arduino IDE. Even though their version has a higher number, it has been much less actively developed than the arduino.cc IDE.
Thanks very much pert. That's useful to know.
BTW. Before ditching 1.7.11 entirely, I did test if it's loader (ld.exe) was compatible with the 1.6.12 version that I'm using, and indeed it was. So as an experiment I'm now running 1.6.12, but wit the loader from 1.7.11.
Given that the problem seems to be in the loader, and that 1.7.11 has been reported (well by at least one person anyway) not to have the bug, I figure it's worth a try.
BTW. All my sketches are compiling properly at the moment, but when I was first testing my arduino I came across a few really simple sketches (like small modifications to the blink example) that would get the loader error. It would be really useful if someone with the XP issue could post a really simple example of a sketch that crashes. Something we could use for testing workarounds against.
Here's a sketch that throws the notorious error (XP, 1.6.12)
void setup() {
Serial.begin(9600);
}
void loop() {
char buffer[50];
uint16_t n = 0;
sprintf(buffer, "%5d ", n++);
Serial.write(buffer);
delay(1000);
}
Results of compiling in various compositions:
| 1.6.12 | error |
|---|---|
| 1.7.11 (arduino.org) | ok |
| 1.0.6 | ok |
| 1.6.12 with ld.exe from 1.7.11 | error |
mangomichl:
Here's a sketch that throws the notorious error (XP, 1.6.12)
Thanks very much mangomichl. Yes sure enough that little program threw the error for me.
I've saved that in a file called crashTest.ino and will use it as a test for any suggested fixes or workarounds that I may come across.
Too bad, but in the meantime I had the problem even with my favoured solution (IDE 1.7.11.from arduino.org). However up to now I could always solve it with the "add some global variables" approach. Serendipitously I ran into a little sketch that is small enough to post it:
//--- crashTestBlink.ino
uint8_t dummy1 = 1;
uint8_t dummy2 = 2;
uint16_t dummy3 = 3;
int16_t dummy4;
int8_t dummy5;
// int dummy6; // decomment for successful compilation
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
digitalWrite(LED_BUILTIN, 0);
delay(100);
digitalWrite(LED_BUILTIN, 1);
delay(1000);
}
The code compiles with variations in the global variable layout, too. E.g. use only the first three variables (--> 5 exit status) but initialize them with 0 or leave them uninitialized (--> ok).
Needless (?) to say: 1.6.12. had no problems with either of these variations.
"It is to hair-scuffel" 
I hesitate to comment because I literally have less than 2 weeks of experience in the Arduino world, but ... for whatever its worth ...
I'm coming to the conclusion that the problem is hardware related. I have multiple computers all running Windows 10, and everything works fine on some of the computers and not at all on others. On some I can make it work if I reboot and don't run any other software.