Compilation (linking?) fails in 1.5.6r2, but ok in 1.5.4 #1901
Labels
Comments
|
This is a bug in the gcc compiler. It's a very rare bug and is triggered when a very specific amount of global variable is allocated. We are in the path to upgrade the gcc compiler in a future 1.5.x release, this should definitely solve this issue. A quick workaround you may try (that worked for me the last time I've got this error) is to add a global variable at the beginning of your sketch even if you don't use it. |
|
Ok, thanks. I've tried adding a global (int, long, or double) to the top of my sketch and it hasn't made a difference, is there a particular size to avoid? |
|
Oh well, maybe it wasn't adding a global variable to the beginning, I vaguely remember the solution, so my previous suggestion is probably wrong. A better explanation of the problem is here: http://stackoverflow.com/questions/8188849/avr-linker-error-relocation-truncated-to-fit The one that best fit my understanding of the problem is this one: |
|
Thanks for that.. the problem makes sense for me, but the padding solution doesn't seem to work for me for some reason - i tried about 50 different sizes and alignments but nothing worked. I guess i'll live with it until a future release and go back to 1.5.4 for the moment. Thanks for your help. |
|
@Mbat, perhaps you could try the nightly version with updated toolchain to confirm that is indeed fixed for you? This build is essentially the ide-1.5.x branch with an updated toolchain, so it's pretty close to the 1.5.6 release. See: https://groups.google.com/a/arduino.cc/forum/#!topic/developers/21G5w2HbUOg |
|
OK, will try it... |
|
I cant seem to get the nightly to run. The mac complains it is "damaged" and only lets me move it to trash. I assume this is a signing issue, and that's apples way of telling me it is incorrectly signed. I don't have a windows machine handy today sorry. |
|
Uhm I see two possible problems: upload failed silently (we had this issue a couple of times with that cloud hosting) or signing. For the record, nightly builds are NOT signed and never will be. Signing obliges us to use the target OSs and we don't have macosx or windows servers: we build on linux the three versions. |
|
Well, the size is about right when it downloads... but I've tried the uncertified developer work around (opening it by right clicking and doing an open from the menu) and that still thinks it's "damaged" I'm not sure what's going wrong... BTW; I downloaded it a few times just in case it really got damaged. |
|
Tried again this morning, to get the latest Nightly, and that is "damaged" (according to OSX) too. |
|
UPDATE: this is now happening in 1.5.4nightly as well, I assume I've gone past some size limit somewhere. So, any suggestions of workarounds very gratefully received, as my business is stuck until I can compile again or try the new nightly. |
|
macosx nightly has just been restored. can you try again? |
|
Just tried, and I still get the "Arduino is damaged" message no matter how I access the package. However I can "show package contents" on it without error. I'm not ruling out that this may be me or my mac, and not the binary... (but other app packages do download and run OK) |
|
Finally got the Arduino Nightly downloaded 3 days ago (see above) to run (needed to set the OSX to allow running any unsigned app). It still gives me the same error. I have narrowed down what is triggering it though; It is to do with the number of print statements where I use the 'F('text" )' notation to store the text string in flash. If i remove some of these, and just store it in RAM I dont get the compilation issues. I can have some (quite a lot) of the F() before I get an issue, but I seem to go over some limit. For me, Ram is less of an issue as i'm using a 256K memory expansion so I can continue working by un-flashing the strings. |
|
I'm still getting this error when using the latest nightly (1.5.6r2) builds. It takes more strings moved to flash using the F("....") directive to trigger the issue, but it still happens. Example; ... ... with this error; Arduino: nightly (Mac OS X), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)" /Applications/Arduino-18apr.app/Contents/Resources/Java/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr6/crtm2560.o: In function Does anyone know if the linker fix is implemented yet in the nightly builds? Thanks, MB |
|
Hi @Mbat http://downloads.arduino.cc/arduino-avr-toolchain-nightly-gcc-4.8.1-linux32.tgz This should solve your problem (I really don't know why we didn't suggested this before...). |
|
Thanks Christian, I just got a chance to try this - does the new toolchain version need some different installation process? I ask because it fails to find libraries such a wire.h. Other nightly builds that I get from the arduino download page find existing libraries fine. I just wanted to check I'm not doing something dumb before copying libraries around to make it find them. Mark On 22 Apr 2014, at 15:37, Cristian Maglie notifications@github.com wrote:
|
|
Ooops sorry Cristian... (spelling) On 24 Apr 2014, at 09:43, Mark Batchelour mbatchelour@gmail.com wrote:
|
|
@Mbat, it should work just like a regular nightly or release install AFAIK. Perhaps you could enable verbose build in the preferences and put up the sketch you are trying and the entire compiler output (the bottom part of the screen in the IDE) on pastebin.com (or something similar)? |
|
Thank Matthijs, It's a bit odd, when I compile an example sketch for the digole library (which is where the unresolved library seems to happen) it compiled fine, but my code fails with the error below; My code starts; ... // -------------------------------------------- code --------------------------------------- |
|
Hmm, what I think is happening is that the DigoleSerial libraries depends on the Wire library. However, the IDE does not (yet) automatically detect this, it only looks at the main sketch to determine what libaries to include in the build. I suspect that your .ino sketch file does not If this is indeed the case, the real question is why it did work with the regular toolchain version... |
|
Yes, it's odd... Here is the successful compilation with the 18th April nightly from the download page; I'm not too worried as I can fix the wire.h issue - but just wanted to make sure i'm not doing something wrong as it behaves differently from the "official' download version. Mark B |
|
Weird. Could you paste the first 30 lines or so of DigoleSerial.h (or link to a download of the version you are using)? |
|
Sure Matthijs; Mark //Digole Digital Solutions: www.digole.com #include <inttypes.h> // Communication set up command #define Serial_UART 0; class DigoleSerialDisp : public Print { DigoleSerialDisp(HardwareSerial *s, unsigned long baud) //UART set up .... etc...... ad so on...... |
|
Ok, nothing funny in there either. It's interesting that the compiler commandline is actually pretty much identical, except for the path to the .app, of course. It's this command that I would expect to fail: I'm wondering if perhaps the |
|
Can you give me a few days to fix the includes issue, then recompile and re-instate the code i've removed as workarounds? I'm travelling today/tomorrow, and will be back in the office on Monday. Thanks, Mark B On 26 Apr 2014, at 20:43, Cristian Maglie notifications@github.com wrote:
|
|
No problem, thanks for checking this one. |
|
Cristian, Ive started to do a bit of testing, but run into a difference in the compiler I think; It seems to handle PROGMEM differently. A couple of my own libraries that use PROGMEM to store arrays in flash fail to compile ( I can stub them out ok), and the SDfat library fails too. While this isn't a big issue to quickly stub out, doing so will mean I use less flash, and that was what triggered the original problem - so I really need to go through, and make all PROGMEM access const to get a valid test of the new linker. It might take me a couple of days to get to this i'm afraid. Mark |
|
Cristian, I finally got time to test the new toolchain version, and it does seem to fix the issue with storing too many strings in flash. I can now do as many Serial.print(F("xxx")); as I like without the linker error. However, there is still a problem in that includes seem to work differently in this version. As noted with the discussion about wire.h, but there is also another example of weirdness; The following code throws an error because one of the variables stored in PROGMEM in SDfat.h is not declared as a const. This seems different from 156r2 release version, which doesnt care about the const. Mark B |
|
PROGMEM data must be now declared "const" this is a new constraint of the updated gcc. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I hope this is the correct way of posting an issue found.., I've also posted it in the troubleshooting section of the forum just in case;
I just made the move from 1.5.4 (nightly build, not sure precisely which night) to 1.5.6r2 (not nightly).
My process went as follows;
in 1.5.4, compile and load the code (Mega 2560 target)- OK
download 1.5.6r2 from the arduino site - OK
rename download to Arduino156r2 and move to Applications folder - OK (so as to not overwrite the old arduino image just in case)
open 156r2 and load sketch - OK
Select target board (2560) -OK
build - FAIL, see error below;
Then I moved back to 1.5.4; and re loaded the sketch, and it still compiles fine.
Other sketches compile fine in both 154 and 156r2.
Any help or suggestions would be appreciated;
MB
The text was updated successfully, but these errors were encountered: