Library compiling different on linux? (SOLVED)

All,

First post in the Arduino forum although I’ve been using the platform for a couple years now. I say this because it speaks to the quality of the platform and the community, because every question I have had over those couple years, was already discussed and answered in these forums somewhere…until now.

I have been searching and searching, for the past three days, and I can not find an answer to an issue I’m having.

I have a library (ArdOSC GitHub - recotana/ArdOSC: Open Sound Control(OSC) Library for Arduino (tested Arduino 1.0-rc1 & Arduino Ethernet)) that I’m making changes to, so it can better fit my application. The library has some common headers, that reside in a sub-directory, of the main library. I make changes and then use the “Verify” in the IDE to compile said changes. This process works on my Mac (OS X 10.6) and Windows (XP and Win7) computers, but fails on my linux (Ubuntu 11.10) box.

For some reason, the linker is not descending into the sub-directory containing the common header files, and the compile fails, with the errors of “file not found” for each file in that directory.

Of course, my first thought was, that something is wrong with the include path being feed to the linker. But, if that were true, why is it only failing on linux?

The references properly add the sub-directory to the #include statement. For example:

#include "OSCcommon/OSCServer.h"

Since the include path reference in the main directory of the library, that is the correct location for that header file. However, I still get a “file not found” on that, and all of the other ones.

Anybody have any idea why this only fails on linux?

EDIT: Never mind guys. Turns out that my answer was in the pull requests on github. Turns out that some of the #include statements, are incorrectly using a upper case ‘C’ for the word “common” in "OSC**Common", and the directory uses an lower case (OSCc**ommon).

I guess I didn’t really look as hard as I needed to at the case of the #include statements, because it compiled fine on OS X. But then why the heck did compile correctly on OS X?