LTO makes the linker fail

[jantje]

I tried to compile a sketch using LTO but it fails to compile. I tried both the Arduino IDE and in the Arduino eclipse plugin named Sloeber.
The only thing I found which looks related is arduino/Arduino#660 but I failed to find a fix.

"C:\Users\jan\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\4.8.1-arduino5/bin/avr-gcc-ar" rcs  "C:\Users\jan\AppData\Local\Temp\builded93937a356f442e64258638d5839ab9.tmp\core\core.a" "C:\Users\jan\AppData\Local\Temp\builded93937a356f442e64258638d5839ab9.tmp\core\wiring_pulse.S.o"
C:\Users\jan\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\4.8.1-arduino5/bin/avr-gcc-ar: Cannot find plugin 'liblto_plugin-0.dll'

[MCUdude]

You'll need GCC 4.9.2 in order to get LTO working. I had an issue where GCC 4.8.1 where still in use even if I used IDE 1.6.12. Removing the MightyCore folder in the /Users/Hans/Library/Arduino15/packages/MightyCore directory and reinstalling it did the trick, and the IDE is now using GCC 4.9.2

[jantje]

I installed mightycore in a fully upto date arduino ide 1.6.11 and he is picking up 4.8.1.
I installed Arduino IDE 1.6.12 same problem.
Deleted the MightyCore folder in Arduino15 folder and reinstalled. Still picking up 4.8.1.
4.9.2-atmel3.5.3-arduino2 is available both to Sloeber as to the Arduino IDE.
So your workaround does not seem to work here

[MCUdude]

Hold on, I actually think I did the changes in the /Users/Hans/Library/Arduino15/packages/arduino/ folder. I don't quite remember which, since I deleted the files. Try renaming the /arduino folder, and see what the IDE does.

[jantje]

I think the problem is related to this
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification/_compare/959b5858c7d4229e374e746fce7cb72719e96a7f...bb372fcbcd3caff25a98f7bf6e22cc2af69b0d4e
because there can be different versions of the same tool you do not know which version you will get.

In other words: As your json file does not specify dependencies you have no control over what {runtime.tools.TOOL_NAME.path} will point to.
because your recipes point to {compiler.path} which points to ${RUNTIME.TOOLS.AVR-GCC.PATH}/bin/
the actually used toolchain is up to the end user his environment.
In my current junit setup I have 200+ different boards and that means I have 2 avr toolchains installed (amongst plenty non avr-gcc tools).
When Sloeber generates the {runtime.tools.TOOL_NAME.path} the order of tool processing will decide on which toolchain will be used. (because the last one will overwrite the previous ones)
I think this can only be fixed by specifying the versions in the tool dependencies. (In the current existing format or in another)

I guess you only have 1 avr-gcc version or -because of what you did and by chance- RUNTIME.TOOLS.AVR-GCC.PATH points to 4.9.2

[jantje]

To confirm my thinking I added

1284.menu.LTO.Os_flto.runtime.tools.avr-gcc.path={runtime.tools.avr-gcc4.9.2-atmel3.5.3-arduino2.path}
to the boards.txt.

In Sloeber now it works fine for 1284.

[jantje]

Did I close this issue?

[MCUdude]

You certainly did! Didn't you solved the problem?

[jantje]

If you change the boards.txt you can force the toochain to whatever you want.
I don't really think this is a solution.
The only good solution I see is enforcing a toolchain in the json file.

[jantje]

I changes sloeber so the newest installed arduino avr platform is dominant.
So this is fixed in a way