The SPI library and the ArduinoRobot library will not compile when both included

[MikaylaFischler]

The compiler (arduino 1.0.5) gives a multiple definition error for all SPI commands when code, including this, is compiled:

#include <ArduinoRobot.h>
#include <SPI.h>
void setup(){}
void loop(){}

Please fix that ASAP, I can't use an SPI interface with the robot!

[barbudor]

To Michael;
Indeed there are conflicts as the ArduinoRobot library already includes SPI
library.
You may remove the SPI library directory from your arduino/libraries
directory when using ArduinoRobot.
Also remove Robot_Control and Robot_Motor when not using the ArduinoRobot.

To Arduino team : this is not the 1st time I see someone with such problem.
=> Such conflict should be avoided or there should be a way to specify
which libraries are enabled depending on the target board.

Thanks

2013/12/1 Michael1516 notifications@github.com

The compiler (arduino 1.0.5) gives a multiple definition error for all SPI
commands when code, including this, is compiled:

#include <ArduinoRobot.h>
#include <SPI.h>
void setup(){}
void loop(){}

Please fix that ASAP, I can't use an SPI interface with the robot!

?
Reply to this email directly or view it on GitHubhttps://github.com//issues/1709
.

[MikaylaFischler]

Thanks! And I agree, the compiler should not act like this.

[matthijskooijman]

Could you elaborate a bit on how it's broken exactly? Pasting compiler output and errors would be helpful.

I just quickly tried this on my 1.0.5 and got an error:

/usr/share/arduino/libraries/Robot_Control/keyboard.cpp: In member function ‘int8_t RobotControl::keyboardRead()’:
/usr/share/arduino/libraries/Robot_Control/keyboard.cpp:31:42: error: ‘KEY’ was not declared in this scope
   lectura_pul = this->averageAnalogInput(KEY);

However, I'm not sure that this is the same error you are referring to?

[tatic0]

Hi,

I was testing an example from Adafruit and I got:

In file included from /usr/share/arduino/libraries/Robot_Control/SquawkSD.h:4:0,
from /usr/share/arduino/libraries/Robot_Control/ArduinoRobot.h:6,
from /usr/share/arduino/libraries/Robot_Control/keyboard.cpp:1:
/usr/share/arduino/libraries/Robot_Control/Fat16.h:260:25: warning: ‘prog_char’ is deprecated [-Wdeprecated-declarations]
/usr/share/arduino/libraries/Robot_Control/Fat16.h:261:27: warning: ‘prog_char’ is deprecated [-Wdeprecated-declarations]
/usr/share/arduino/libraries/Robot_Control/keyboard.cpp: In member function ‘int8_t RobotControl::keyboardRead()’:
/usr/share/arduino/libraries/Robot_Control/keyboard.cpp:31:42: error: ‘KEY’ was not declared in this scope
/usr/share/arduino/libraries/Robot_Control/keyboard.cpp:29:14: warning: unused variable ‘anterior’ [-Wunused-variable]

Does this help?

[jantje]

This is probably the same issue as I reported on 4 november on the developers list.
https://groups.google.com/a/arduino.cc/forum/?fromgroups#!topic/developers/ku32KnasSm0

[matthijskooijman]

@jantje, I'm not sure what mail you are referring to exactly? Neither of your posts to that thread seem related to me?

Furthermore, it seems that the KEY was not declared error is not the same error the original reporter was referring to. He talks about multiple definitions for all SPI identifiers. Looking more closely, I see that the KEY macro is defined in the pins_arduino.h file for the Robot_control board. In other word, we get it because we didn't select the Robot_Control board. If I change to the Robot_control board, I get the SPI errors the poster mentioned:

SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:63: multiple definition of `SPIClass::begin()'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:63: first defined here
SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:64: multiple definition of `SPIClass::end()'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:64: first defined here
SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:64: multiple definition of `SPIClass::setBitOrder(unsigned char)'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:64: first defined here
SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:64: multiple definition of `SPIClass::setDataMode(unsigned char)'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:64: first defined here
SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:64: multiple definition of `SPIClass::setClockDivider(unsigned char)'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:64: first defined here
SPI/SPI.cpp.o: In function `SPIClass::setClockDivider(unsigned char)':
/usr/share/arduino/libraries/SPI/SPI.cpp:63: multiple definition of `SPI'
Robot_Control/SPI.cpp.o:/usr/share/arduino/libraries/Robot_Control/SPI.cpp:63: first defined here
collect2: error: ld returned 1 exit status

Out of time for now, I'll try to have a look tomorrow.

[jantje]

The problem I refer to is in regards to the remark
==You may remove the SPI library directory from your arduino/libraries

Arduino finds libraries based on .h names. It also prefers user installed libraries to arduino delivered libraries.
So if you include the SPI library arduino will add the line #include <SPI.h>
if you create a folder called x containing a empty file SPI.h in your libraries folder the sketch will not compile.
This because arduino will find x/SPI.h and add x to the build and include path and not the SPI folder
Best regards
Jantje

[matthijskooijman]

@jantje, I see, thanks!

It looks like the Arduino_Control library indeed contains a verbatim copy of the SPI library (SPI.cpp and SPI.h are identical to the ones in the SPI library). I presume this is so you can add the Arduino_Control library and things will work, without requiring the user to include SPI.h in their sketch as well (@cmaglie, you added these files, am I correct)? However, the side effect of this is that when you do include SPI.h, the IDE will link against the real SPI library as well, causing these conflicts.

Removing the SPI.cpp and SPI.h files from the Arduino_Control library is the proper way to fix this. However, as a side effect, we'll break every sketch that uses Arduino_Control, because those no longer link against the SPI code.

The proper fix for this again is to make the IDE aware of inter-library dependencies, either by autodecting (#236 / #1250) or by allowing a library to explicitely specify it's dependencies in a library.properties file or something. Until either of these is implemented, I don't think we can fix this particular issue.

As suggested before, if you need to make things compile right now, you can remove the either the SPI library, or I think also the SPI.cpp and SPI.h files from the Arduino_Control library as a workaround.

[matthijskooijman]

Note that, as reported in #1599, all of this also applies to the Wire lib (which is also included in Robot_Control).

[cmaglie]

Hi guys, and thanks for the analisys.

I don't know why a verbatim copy of SPI and Wire are "bundled" in the Robot_Control library. When I looked at #1599 I thought that the Wire copy was an "optimized" version specific for the Robot, but now I realized that is exactly the same as the standard Wire library, so to me it doesn't make sense anymore to have it just copied there. @dcuartielles and @X-Y, since you authored the library, may you explain why? I'm for removing the SPI and Wire copy (and any other eventual exact copy of sub-libraries included in the Arduino_Robot).

About the other issues, I'm going to give a look to the recursive "include" problem.
Note that we are discussing about two different issues here:

1. The linking of libraries that depends on another library: issues Include library paths used by libraries in the compiler search path. #1250 and Auto-detect dependencies between libraries [imported] #236

2. The library selection logic as reported by @jantje : this is another tricky problem and it deserve a specific issue to be discussed properly (I'm opening a specific issue for that in a minute).

C

[X-Y]

Hey guys!
These libraries are included as a copy so you only need to have one include (<ArduinoRobot.h>) at the beginning of a sketch. Otherwise you have to include them all again. Also, since the robot memory is extremely limited, any change to the external libraries may add a few more bytes and disable the examples(The TFT library has already proved to be such a case).
So if anybody has a suggestion about how to solve these two problems, feel free to share :) Thanks!