External library not used

At compilation, I receive the messages:

Multiple libraries were found for "SPI.h"
Used: C:\Users\Damir\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\libraries\SPI
Not used: D:\Users\Damir\Documents\Arduino\libraries\SPI

Please note that the #include statement uses double quotes:

#include "SPI.h"

I have found a workaround: renaming the SPI folder to, say, SPI_junk, the message is:

Multiple libraries were found for "SPI.h"
Used: D:\Users\Damir\Documents\Arduino\libraries\SPI
Not used: C:\Users\Damir\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\libraries\SPI_junk

However, this does not work in Linux version so I am stuck with windows.

The problem is not new. The last correct version was windows portable 1.6.8 (yes it is old, I know). I have also tested windows portable versions 1.8.3, 1.8.5, 1.8.15 and all have the same problem (and the same workaround). I have also tested linux versions 1.8.13, 1.8.15, and 2.0.0 beta, and none of them will compile the sketch correctly.

The factors that determine which library is selected when multiple match an #include directive are documented here:

Note this part:

Location PriorityΒΆ

The "location priority" is determined as follows (in order of highest to lowest priority):

... (irrelevant factors)

  1. The library is under the libraries subfolder of the IDE's sketchbook or Arduino CLI's user directory
  2. The library is bundled with the board platform/core ({runtime.platform.path}/libraries)

So if all the other factors are the same, then your library in D:\Users\Damir\Documents\Arduino\libraries will have higher "Location Priority" than the one in C:\Users\Damir\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\libraries and be picked.

This means there is some other more important difference between the two libraries that is causing the other to get priority. We know it's not "Folder Name Priority" because both libraries have the same folder name. So it must be "Architecture Matching". You can check by opening the metadata file in a text editor:


But we also might investigate exactly why you want to do this thing. It is very unusual to install the SPI library under your sketchbook. This can cause problems because the SPI library contains architecture-specific code. So, for example, the SPI library written for the AVR architecture of the Uno is completely different from the one written for the ESP8266. This is the reason the SPI library is bundled with the boards platform.

The platform bundled libraries are only accessible when compiling for a board of that platform. So this means that the IDE will automagically use the right version of the library for each board. Ideally, the fact that completely different libraries are used from one board to another isn't noticeable to the user because all the versions of the library use a standardized API, so the code that uses that API will work for every board. But the sketchbook installed libraries are always accessible. So when you install a library like SPI there, you might end up in a situation where a library is being used for a board it's not written for, which could cause very confusing results. In practice, "Architecture Matching" will usually ensure that the right library is picked, but that's not guaranteed.

The dependency resolution system works exactly the same on every operating system. So there must be some other factor in play here.

Thank you for your answer. Unfortunately, it does not tell me anything I do not already know. The "location priority" used to work as described up to and including IDE version 1.6.8. Here is the relevant compiler message:

Multiple libraries were found for "SPI.h"
Used: D:\Users\Damir\Documents\Arduino\libraries\SPI
Not used: D:\Portable Apps & Utils\arduino-1.6.8\hardware\arduino\avr\libraries\SPI

Every version 1.8.x I tried (and I tried quite a few) detected my external library but insisted on using its own! Ditto for 2.0.0 beta. I listed the compiler messages in my first post

Under Windows, renaming the preferred library solved the problem. Under Linux, your claim to the contrary, that is not the case.

Why I need the different SPI library? Well, standard SPI port on Arduino Uno uses pins D10, and D11 for SS and MOSI. This pins can also be controlled by internal Timer1B and Timer2A which is what I need. Thus, I have no choice but to use USART as SPI port. So, I hacked an alternative SPI library. I use the same name (SPI) in order to redirect all SPI users (other libraries) to it. I did not check, but is USART SPI now an option?

Best regards.

The dependency resolution system has evolved over time. Location is only one of the factors.

Did you do this?

Please post the contents of that library.properties file here.

Hello again!

Well, my library did not have "library.properties" file. The only excuse I have is that back in 2014, when I wrote my library, this file was not mandatory. I copied the one from IDE and that solved the problem. Now everything works under Windows, as well as, under Linux.

As I mentioned, I only copied the file and have no idea what it does. At a moment, the content does not seem to matter, but for the future, where could I find the syntax of its commands? Other than that, the problem is solved.

Thanks again and best regards

For the Arduino IDEs and Arduino CLI, it still isn't mandatory (it is when using Arduino Web Editor). Backwards compatibility with the old library format was retained when the new format was introduced in Arduino IDE 1.5.x.

The reason this changed the priorities is because when there is no library.properties, this is the equivalent of specifying a wildcard architecture compatibility:


But the stock Arduino SPI library bundled with Arduino AVR boards specifies that it is optimized for the avr architecture:


Architecture optimized libraries get priority over architecture compatible libraries, which tipped the scales to the one in C:\Users\Damir\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.3\libraries\SPI.

Here it is:

I'm glad to hear it!

You're welcome.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.