Boards manager install of older avr-gcc breaks compilation for all AVR boards in 1.6.10.

[damellis]

A user of the attiny boards package encountered this: damellis/attiny#105

The previous ATtiny package json (https://raw.githubusercontent.com/damellis/attiny/f026e80bc8fa4e33714bfe28ceafdd8829d85293/package_damellis_attiny_index.json) included explicit dependencies on the avr-gcc and avrdude versions that came with Arduino 1.6.9 (and previous). With 1.6.10, newer versions of these tools are included, so installing the ATtiny package also installed these older tools. These older tools then get used for all AVR boards.

It appears the older tools don't support LTO or plugins, so compiling in 1.6.10 gives the error:

sorry - this program has been built without plugin support
exit status 1

I think I fixed this for the ATtiny package by removing the explicit tool dependency, and assuming that avr-gcc and avrdude will be included with the Arduino IDE.

This may remain a problem for other third-party hardware packages, though. Maybe the IDE should use the bundled avr-gcc and avrdude for bundled boards even if another version has been installed for other boards? Maybe only if the newly-installed version is older than the bundled version?

[damellis]

Also, is there a way for a third-party hardware package to specify dependency on a tool, but not a particular version of it? Or to depend on a range of versions (e.g. some particular version or later)?

[jantje]

Work around: install 1.11 avr arduino toolchain
Note currently you can not install 1.12.
This means the optimisations are no longer available. As soon as 1.13 comes out (or is specified in the json file) you can use 1.13 and have the optimisations.
Root cause of the issues: preinstalled toolchains are not properly identified.

[facchinm]

Hi everyone,
we spot the bug too late (the fact that the PR adding the new toolchains had a hack to overcome an IDE limitation is the key here) and we are working on a fast solution (making the builder more intelligent). Expect some bugfix release really soon. Sorry for any inconvenience.

[jantje]

Thanks for confirming this is a bug.

[MCUdude]

@per1234 does this means that I can just leave the JSON file as it is, or just upgrade the Tooldependencies field?

[per1234]

@MCUdude I won't know for sure until there is an hourly build with a fix that I can test. It does possibly offer the option of just letting the issue be fixed in the IDE. The problem with that solution is anyone who has installed Arduino IDE 1.6.10 in the meantime remains vulnerable to having their Arduino AVR Boards core broken by installing any of your cores.

I'm glad to see facchinm is working on a fix.

[cmaglie]

The attiny:avr package uses the core from the arduino:avr package as specificed in the boards txt with the line:

ATtinyX5.build.core=arduino:arduino

This means that the package attiny:avr needs the same set of tools but also the platform.txt and the arduino core from the package arduino:avr. When we changed platform.txt of arduino:avr, to enable LTO, we also break the attiny:avr package because it referenced explicitly the older set of tools that did not support LTO. So in this case removing the explicit reference to the old tools is a good fix.

Also, is there a way for a third-party hardware package to specify dependency on a tool, but not a particular version of it? Or to depend on a range of versions (e.g. some particular version or later)?

The real issue is that the package_index.json misses the information that attiny:avr uses arduino:avr and, at the moment, there is no way to explicitly state this.

A better solution IMHO is to add a new field coreDependencies in the package_index.json , something like this:

        {
          "name": "attiny",
          "architecture": "avr",
          "version": "1.0.1",
          "category": "attiny",
          "help": {
            "online": ""
          },
          "url": "https://github.com/damellis/attiny/archive/76ca88ce3c195fcba8e8a645084e352965dc80e0.zip",
          "archiveFileName": "76ca88ce3c195fcba8e8a645084e352965dc80e0.zip",
          "checksum": "SHA-256:49a4dfc3796caf2533050b0b962ae0affb2471b8ded1283936d7b712cc1fdff1",
          "size": "5719",
          "boards": [
            {"name": "ATtiny45"},
            {"name": "ATtiny85"},
            {"name": "ATtiny44"},
            {"name": "ATtiny84"}
          ],
+         "coreDependencies": [
+             { "packager": "arduino" }
+         ],
          "toolsDependencies": [
-           {
-             "packager": "arduino",
-             "name": "avr-gcc",
-             "version": "4.8.1-arduino5"
-           },
-           {
-             "packager": "arduino",
-             "name": "avrdude",
-             "version": "6.0.1-arduino5"
-           }
          ]
        }

Doing this way we know explicitly that attiny:avr uses arduino:avr and therefore inherits all the tools from arduino:avr (no need to specify them).

[jantje]

Doing this way we know explicitly that attiny:avr uses arduino:avr and therefore inherits all the tools from arduino:avr (no need to specify them).

... for the arduino IDE.

[cmaglie]

... for the arduino IDE.

@jantje
may you be a bit more explicit?

You may be surprised, but I proposesd this change to help 3rd party tool developers, in particular you, to gather all the information needed exclusively from the json package_indexes.

[jantje]

@cmaglie
I'm just stating that the Arduino eclipse plugin named sloeber does need to have the tools specified to work properly. I assume there are other IDE's around that need this as well.
As the data is static I do not think there is a big gain in not specifying.

[cmaglie]

Arduino eclipse plugin named sloeber does need to have the tools specified to work properly.

I know, that's why I proposed to remove toolDependency but at the same time add coreDependencies.

Look at the attiny:avr example above: it uses the core (and consequently the same tools) of arduino:avr.
So why repeating? just state that with:

         "coreDependencies": [
             { "packager": "arduino" }
         ],

and you know that attiny:avr needs the same tools from arduino:avr (that are specified in the main package_index.json).

from package_index.json:

{
  "packages": [
    {
      "name": "arduino",
      "maintainer": "Arduino",
      "websiteURL": "http://www.arduino.cc/",
      "email": "packages@arduino.cc",
      "help": {
        "online": "http://www.arduino.cc/en/Reference/HomePage"
      },
      "platforms": [
         ...SNIP...
        {
          "name": "Arduino AVR Boards",
          "architecture": "avr",
          "version": "1.6.12",
          ...SNIP...
          "toolsDependencies": [
            {
              "packager": "arduino",
              "name": "avr-gcc",
              "version": "4.9.2-atmel3.5.3-arduino2"
            },
            {
              "packager": "arduino",
              "name": "avrdude",
              "version": "6.3.0-arduino2"
            }
          ]
        },

As the data is static I do not think there is a big gain in not specifying

The problem is that this data is not always static, in particular packages that uses cores from another package (like attiny but basically 90% of the packages around) needs the same tools from the referenced package that may change when the referenced package is upgraded!

[jantje]

@cmaglie
It is once again clear to me that we come from 2 different planets.
Because of that I decided a long time ago to stop discussing and work with what comes out of the Arduino core team and live with it.
My body advices me to stick to this policy.

[PaulStoffregen]

Expect some bugfix release really soon. Sorry for any inconvenience.

Version 1.6.11 ??

[cmaglie]

It is once again clear to me that we come from 2 different planets.

@jantje
may I know what could be a reasonable solution to this issue for you?

Version 1.6.11

@PaulStoffregen
that's the idea