Travis fails since dot_a_linkage was added to SPI and Wire library

[MCUdude]

@per1234 can you look into this? I've looked at the log but nothing stands out to me.
Detailed output can be found in Travis job no. 90.

[per1234]

The issue is not specific to the Travis CI build. The same compilation error will occur if you compile the SD or Ethernet library example sketches with the Arduino IDE.

After some investigation, I found that the problem only occurs when the #include directive for SPI.h comes before the #include directive for Ethernet.h or SD.h in the sketch:

Error:

#include <SPI.h>
#include <Ethernet.h>
void setup() {
  byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED};
  Ethernet.begin(mac, IPAddress(192, 168, 1, 177));
}

void loop() {}

Success:

#include <Ethernet.h>
void setup() {
  byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED};
  Ethernet.begin(mac, IPAddress(192, 168, 1, 177));
}

void loop() {}

Success:

#include <Ethernet.h>
#include <SPI.h>
void setup() {
  byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED};
  Ethernet.begin(mac, IPAddress(192, 168, 1, 177));
}

void loop() {}

It seems that the order of the files in {object_files} in recipe.c.combine.pattern is affected by this and if SPI.a comes too early in the command, it results in the compilation error.

Here's the working recipe.c.combine.pattern:

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino5/bin/avr-gcc" -Wall -Wextra -Os -Wl,--gc-sections -mmcu=atmega1284p -o "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489/dotatest.ino.elf" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\sketch\\dotatest.ino.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\File.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\SD.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\Sd2Card.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\SdFile.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\SdVolume.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SPI\\SPI.a" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489/core\\core.a" "-LC:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489" -lm

Here's the non-working one:

"C:\\Users\\per\\AppData\\Local\\Arduino15\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino5/bin/avr-gcc" -Wall -Wextra -Os -Wl,--gc-sections -mmcu=atmega1284p -o "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489/dotatest.ino.elf" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\sketch\\dotatest.ino.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SPI\\SPI.a" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\File.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\SD.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\Sd2Card.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\SdFile.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489\\libraries\\SD\\utility\\SdVolume.cpp.o" "C:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489/core\\core.a" "-LC:\\Users\\per\\AppData\\Local\\Temp\\arduino_build_193489" -lm

Notice that in the working one, SPI.a comes near the end, just before core.a. In the non-working one, SPI.a comes near the start, just after dotatest.ino.cpp.o.

The example sketches could easily be modified to compile by changing the order of the #include directives, but there's no guarantee the users will put them in the required order in their own sketches.

[MCUdude]

We don't really solve anything by modifying the sketches. Yes, Travis will eat it but there's still a hidden trap in there.

What do you suggest we do? This must be a bug in the builder, right?

[per1234]

I'm really out of my depth with this topic. I only figured out as much as I did after a lot of fumbling around. It certainly does seem like a bug, but I just don't have the level of understanding about what's happening to be able to say for sure. Maybe it's only that some magical change needs to be made to the SPI and Wire libraries that will make it not an issue.

If it is a bug, it would be great to get it reported to Arduino so it can hopefully get fixed soon. I don't think many people are using the dot_a_linkage, so a bug could very well have never been noticed. From matthijskooijman's description, it does seem like a very useful feature though.

If it is a bug, even if Arduino fixes it immediately there is still the issue of backwards compatibility with all the previous IDE versions that still have the bug.

[MCUdude]

I'm really out of my depth with this topic.

Mee too. I don't know too much about the building process itself and all things involved.

If it is a bug, even if Arduino fixes it immediately there is still the issue of backward compatibility with all the previous IDE versions that still have the bug.

That is true. However, if they fix it in a newer version, we can point users who are experiencing this problem to use the latest version.

Where should this issue be reported? It would be great if some of the developers would look into this. dot_a_linkage is indeed useful!

[per1234]

Where should this issue be reported?

I'm pretty sure arduino-builder is where dot_a_linkage is handled:
https://github.com/arduino/arduino-builder

[MCUdude]

I decided to "roll back" to prevent breaking existing user code. Wire1.h will now have to be manually included. IMO I think this is the best solution for now.