many cases of ld.exe crashes. (on windows xp).

After downloading 1.6.4 I was having numerous crashes (collect2.exe: error: ld returned 5 exit status) with even the simplest of sketches, I copied the ld.exe from 1.0.5 into the latest 1.6.4 download, and everything now works great! I used 1.0.5 instead of the previously mentioned 1.0.6, because I already had it downloaded. Using Windows XP SP3.

//thanks the idea appears to work //I add the following global variable long xxxx[0]; // added to eliminate ID.exe crashes

// add a global variable long xxxx[0]; //Added to eliminate ID.exe crashes

finally I found out that I was repeatedly replacing the wrong ld.exe. Did a “Installer” install to D: in the beginning (but didn’t recognize that compiler & co ended up in my userprofile) later replaced D:\arduino with .zip version where I tried to replace several ld.exe for no avail. Now in the correct place it seems to work.

Going to clean up the mess and never touch that “installer” stuff again.

P.S.: the trick with adding global variables never worked for me. A method to break compiling for ~100% was adding serial output. Sometimes serial.print was ok in the setup but definitely broke it in loop.
It is very discouraging if you start something new and already fail with the examples …

First time I had the problem I fixed it by replacing ld.exe from an older version - thanks to you guys.

Then I messed up my installation by installing MegunoLink's Upload Monitor. If you are using MegunoLink and started to get a bunch of "not valid win32 app" errors, close the IDE and remove that Upload Monitor thing using MegunoLink's menus.

Back to the issue. Today I tried the "ld.exe" from the latest nightly build at the download page and it worked! Unless I mixed up files, devs must have fixed the problem. Can someone try to verify this?


PS: that's "LD.EXE" not "ID.EXE". Don't make the mistake I made.

Seems to be a (random) integer division bug in the compiler.

See my post here:

Just a quick note: On a Windows XP SP3 box, with 1.6.4, their “Buttons” example (for example) blows up. Following suggestions here, I put 9 “int” declarations before the setup() and it now compiles fine. (Go iigure).


Is this problem solved with the new arduino IDE 1.6.5 ?

fog44: Is this problem solved with the new arduino IDE 1.6.5 ?

Nope. I just downloaded 1.6.5 and the issue continues..

I had the chance to use a clean windows xp and, sorry to say, the IDE works just fine. A similar issue has been affecting a windows 8 user: cause was her antivirus, that was blocking access to some files shipped and used with the IDE. Can you double check your quarantine or something?

Is this problem solved with the new 1.6.5 IDE ?

definitely NO and I tried with a fresh install of XP/SP3. It seems to depend on a lot of things. I had an example where it wouldn't accept a modulo operator until I swaped two statements some lines above. It then compiled ok until I inserted serial.print() in the mainloop, that broke it for good;, I didn't find a way around swaping ld.exe. And that makes it stable - what to me shows that its definitely some flaw in the newer toolchain.

And - as sidenote - the IDE itself isn't really stable on W7 either. When I leave it open in the background it sometimes disappears on its own, without any further notice ... if you look at the taskmanager you see the javaw gobbling up memory and probably running out of eventually ....

Id crashes. I have through many post about this error and am still puzzled. I have received the message many times, not just in any one sketch. Many of the times have been when I tried to compile a sketch copied from the web with no changes. Someone suggested adding variables into the sketch, no such luck. Instead of the connect2.. message now I am receiving the following error message from the windows operating system. example one AppName: ld.exe AppVer: ModName: ld.exe ModVer: Offset: 0008293b

If I open error report, it will not allow me to copy it but I believe is a key part is Module 1 id.exe image base 0x00400000 image size0x00000000 checksum 0x0011011ee time stamp 0xffffffff version information signature 00000000 strucVer 00000000 file ver(0.0:0.0) prod ver( flag mask flags,os: and file type are all listed as 00000000 I hope this will help someone who knows more than fix this issue. One more not of interest. I did several searches and could not fine id.exe on my xp sp3 machine

no it is not solved. in fact worse. and imo it is foolish to be concerned with coding details. i struggled for couple hours today with it in this thread:

i say worse because the standard fix of simply copying ld.exe from any earlier version is more tricky. from 1.5.8 and some others worked for 1.6.3 but not for 1.6.5. from 1.0.5 did. several projects that misbehaved before are ok now.

btw if windows search does not find it then probably being used incorrectly. mine came up with over 30 instances. i got half way through that list before finding the one (1.0.5) that fixed it.

Hi, you have to look for LD.exe - windows doesn't care for upper/lower case, but for difference between l (lowercase L) and I (uppercase i)! (ha, different fonts for writing/display of posts are a "pita")

To find the one giving you the headache, go into File/preferences and tick "Show verbose output during:" x compilation. In the message window you will see the compilation process and some lines before the error the call of ld.exe with the relevant path. This is the ld.exe you want to swap for an older one.

fog44: Is this problem solved with the new arduino IDE 1.6.5 ?

Issue continues when having Serial.print

I came to the forum today in search of a solution for the same problem that I see many other people are having - compiling with version 1.6.5 r2 for Uno on Windows xp:

The issue of the error happens (in my case) only when Serial.println is used. The code compiles fine if I use Serial.print (without the ln). This bug was not there a couple of days ago (it seems)... as all my files were compiling just fine (but then - I was most often compiling for the Teensy 3.0) ... including files with Serial.println. Suddenly the error occurred when I added Serial.println to a file. I note that I had also switched over to the Uno at some stage. So... if I remove the ln from Serial.println the file will compile and upload. However it seems to me that I have other files that do (or did) compile with the Serial.println ... and as this is a new error that was not occurring previously I am wondering what exactly is triggering the issue.

I wonder if it has to do with the character set interpretation from keyboard settings. I once saw a similar issue with a program that was misinterpreting an apostrophe mark where my keyboard was capable of producing two similar marks... a vertical apostrophe ( ' ) and a slightly slanted apostrophe (that may have been part of a foreign character set). Note: The fact that the code compiles using some of the solutions mentioned below may weed this out as a cause for the problem.

I tried swapping out the ld.exe for version 1.5.8 (which I already had on my computer) and this did not work for me. I see reference here that I need to test specific versions of ld.exe and I will look into that.

I am hoping that someone has now come up with a more permanent and uptodate fix for this.


Update: More interesting tests. Uno: Serial.println("test") - will not verify Uno: Serial.print('\n') - will not verify

Switching to board Arduino Micro - both tests above will verify (compile).

Something going on here with the Uno version that inhibits code which produces new lines in Serial.print.

Update 2: Based on some tips/tests found in the forum on the same issue I added a dud variable to the top of my code: int test=1; (int test; or String abc; will also work) and suddenly my files with Serial.println ( or Serial.print ('\n'); ) will verify/compile.

This is a strange issue indeed. Someone here must know why these little tricks/tests such as adding dud variables will suddenly allow the code to compile. It seems there is a balance... when the code stops compiling (others mention) you must continue to add more dud variables. Is there a size of file/memory issue that needs to fall on just the right mark/division/ratio for the code to compile?

Update 3 As my code length grew and I included more Serial.println I also had to add more dud variables: Code using 25 Serial.println required 12 dud variables... int dud; int dud5; ... int dud12; At some points removing variables also worked so I often tried that first. What most often worked (and to save time) I simply just kept adding a variable until my code would compile. It is a strange balancing act and I am sure someone here can add up these clues to figure out what the problem is and what a better solution would be.

How do I/we get some attention on this issue?

fog44: Is this problem solved with the new 1.6.5 IDE ?

Tried today 1.6.5, after upgrading from formely fixed the same way 1.6.3 - same problem (WinXP machine). Eg. FastLed examples compiles, works, but add any global variable (int, byte, volatile or not) - ld.exe crash'es. Local variables in functions works fine. Copied ld.exe and some missing cygwin libraries from 1.6.0 distribution (simply run ld.exe and see what required), and everything works again.

I just upgraded from 1.6.3 to 1.6.5 yesterday. I want to try someone's posted example code and kept getting this error. I tried modifying it a bit with no luck. I deleted the delay(10); line and the code uploaded successfully.

Same problem here. WinXP SP3, ld.exe “has encountered a problem” and crashes while compiling a simple SoftwareSerial passthrough sketch. Can someone PLEASE fix this?

  Example Bluetooth Serial Passthrough Sketch
 by: Jim Lindblom
 SparkFun Electronics
 date: February 26, 2013
 license: Public domain

 This example sketch converts an RN-42 bluetooth module to
 communicate at 9600 bps (from 115200), and passes any serial
 data between Serial Monitor and bluetooth module.
#include <SoftwareSerial.h>  

int bluetoothTx = 2;  // TX-O pin of bluetooth mate, Arduino D2
int bluetoothRx = 3;  // RX-I pin of bluetooth mate, Arduino D3

SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);

void setup()
  Serial.begin(9600);  // Begin the serial monitor at 9600bps

  bluetooth.begin(115200);  // The Bluetooth Mate defaults to 115200bps
  bluetooth.print("$");  // Print three times individually
  bluetooth.print("$");  // Enter command mode
  delay(100);  // Short delay, wait for the Mate to send back CMD
  bluetooth.println("U,9600,N");  // Temporarily Change the baudrate to 9600, no parity
  // 115200 can be too fast at times for NewSoftSerial to relay the data reliably
  bluetooth.begin(9600);  // Start bluetooth serial at 9600

void loop()
  if(bluetooth.available())  // If the bluetooth sent any characters
    // Send any characters the bluetooth prints to the serial monitor
  if(Serial.available())  // If stuff was typed in the serial monitor
    // Send any characters the Serial monitor prints to the bluetooth
  // and loop forever and ever!