#error unknown CPU

[jwatte]

I'm trying to compile the LSM303 library from Pololu for the Teensy 3.1
I'm using 1.0.6 with the Teensy3.1 installer on top.

I'm getting this error:

Arduino: 1.0.6 + Td: 1.20 (Windows NT (unknown)), Board: "Teensy 3.1"
C:\code\arduino-1.0.6\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=72000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=120 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_SERIAL -DLAYOUT_US_ENGLISH -IC:\code\arduino-1.0.6\hardware\teensy\cores\teensy3 -IC:\code\arduino-1.0.6\libraries\Wire -IC:\code\arduino-1.0.6\libraries\Robot_Control -IC:\code\arduino-1.0.6\libraries\Robot_Control\utility C:\code\arduino-1.0.6\libraries\Robot_Control\ArduinoRobot.cpp -o C:\Users\jwatte\AppData\Local\Temp\build3078802193584194682.tmp\Robot_Control\ArduinoRobot.cpp.o 

In file included from C:\code\arduino-1.0.6\libraries\Robot_Control\Fat16.h:29:0,
                 from C:\code\arduino-1.0.6\libraries\Robot_Control\SquawkSD.h:4,
                 from C:\code\arduino-1.0.6\libraries\Robot_Control\ArduinoRobot.h:6,
                 from C:\code\arduino-1.0.6\libraries\Robot_Control\ArduinoRobot.cpp:1:
C:\code\arduino-1.0.6\libraries\Robot_Control/SdCard.h:76:2: error: #error unknown CPU
C:\code\arduino-1.0.6\libraries\Robot_Control/SdCard.h:91:36: error: 'SPI_SS_PIN' was not declared in this scope
C:\code\arduino-1.0.6\libraries\Robot_Control\ArduinoRobot.cpp: In constructor 'RobotControl::RobotControl()':
C:\code\arduino-1.0.6\libraries\Robot_Control\ArduinoRobot.cpp:8:42: error: 'LCD_CS' was not declared in this scope

and a few more.

The problem is: It's trying to compile the RobotControl library.
None of the files in my project mention or make use of RobotControl.

The only other note about this I've found is on Adafruit support forums:
http://forums.adafruit.com/viewtopic.php?f=47&t=46507
The fix there was to delete the RobotControl library from the installed Arduino. While I'm OK doing that, I'd love to know what's going wrong in the first place -- why is it trying to build this?

 

[PaulStoffregen]

Can you post a link to the exact library you're using?

Oh, there must be some file with the same name as a file in Robot_Control.

Arduino isn't very good about figuring out which library you really wanted. I added some code in 1.20's patches to improve the matching, but it's still not perfect. Seeing the exact library you're using would help me understand why it's failing. Small details matter, which is why we have the "forum rule"....

 

[jwatte]

Oh, there must be some file with the same name as a file in Robot_Control.

That's probably it, then. I had just created a new pair of files named Compass.cpp and Compass.h in my project. Looking at the source, that library has files of the same name:

https://github.com/arduino/Arduino/tree/master/libraries/Robot_Control

Which leads to the question: Make has worked fine for 40 years. Libraries are a solved problem. Why the $^%#% do they have to go an be "special" in the Arduino IDE and just confuse and complicate things like this?

Thanks for the answer/solution!

 

[PaulStoffregen]

Which leads to the question: Make has worked fine for 40 years. Libraries are a solved problem. Why the $^%#% do they have to go an be "special" in the Arduino IDE and just confuse and complicate things like this?

Normally that solution involves editing the makefile if you decide use a library. Or in an IDE, usually a menu or other GUI to say you're using a library.

Make doesn't automatically detect, based only on your code, which of dozens or hundreds of possible extra libraries are supposed to be built into your program. Arduino does. Not always well, but it does. They felt requiring users to explicitly edit a list of libraries to put into the build process added too much burden for novices to learn.

 

[jwatte]

Make doesn't automatically detect, based only on your code, which of dozens or hundreds of possible extra libraries are supposed to be built

Right. But instead of building all the sources at once, and getting confused about source file names, an alternative way of implementing libraries could be:
- for each folder in libraries, build an actual statically linked library (make the .o files, call ar to bunch into a .a)
- when the use of a library is detected, add that -lwhatever option to pick up the .a file, and add the library include path to the compile options
- or it could just include all the .a files in every link, as long as there aren't conflicting symbol definitions

This still isn't perfect, because it still doesn't solve the problem of two libraries providing include files with the same name -- the safer option here is to require all library includes to use the library name (#include <LibFoo/Foo.h>)
Would that be harder for a newbie to pick up than #include <Foo.h> ? I argue "no" -- especially since a typical newbie just copies working code from the web, or uses the "reference library" menu option.

 

[PaulStoffregen]

- when the use of a library is detected,

But how specifically do you implement "when the use of a library is detected" ?

add that -lwhatever option to pick up the .a file, and add the library include path to the compile options

Don't you also need to give -Ipath when compiling other source code which calls the libraries functions? If you only use -lname for linking, but don't provide the include path when compiling non-library code, how will the code which uses the library get proper definitions for whatever API the library provides?

 

[jwatte]

Don't you also need to give -Ipath when compiling other source code

Yes, we agree -- I said "and add the library include path to the compile options"

In my project, I reference my Compass.h with "Compass.h," not <Compass.h> so telling them apart is possible for the compiler. Unfortunately, the IDE doesn't implement the well-defined standard header file path resolution :-(

This is also why I think that the right decision, ye so many years ago, for the Arduino IDE, would have been to reference libraries with the library name <Robot_Control/Compass.h> rather than just <Compass.h>.
This would have required only the -Ilibraries include path, and would have totally avoided any ambiguity.
The C/C++ language, the compiler, linker, and make system, have carefully evolved over > 40 years to be a well functioning system.
My guess (and I'm only guessing here) is that the Arduino IDE makers wanted to "help" newbies by "simplifying," but instead actually didn't really simplify anything, but now instead they have a source of confusion and a lot of legacy code that would break if making it right in a new version.

Although this is probably not the right forum for that discussion -- if I really cared, I'd implement the other way and send a pull request on Arduino.cc

 

[Headroom]

As you seem to have some experience with make files and I am assuming also with better IDE's there are better IDE's that allow you to compile and upload Arduino code and don't have the problem with libraries that the Arduino IDE has.
The Eclipse Arduino IDE/Plugin would be what I use on my iMac.
On Windows there are more alternative. The Visual Micro plugin for Visual Studio has received some praise here on the Forum by very experienced users.