it is not uncommon for different compiler and library writers to interpret the C/C++ standards is subtly different ways
I was going to say that that would be unlikely to affect dependencies (this used to be about dependencies, right?), but then I remember that we ran into EXACTLY that sort of thing.
We had this idea of "components", which were independently compiled things not-quite-like libraries. And there would be code off in #includes like
#define COMPONENT_SOURCE ../../../components/
#define COMPONENT_VERSION 1
so that you could write your include like:
#include COMPONENT(ip, tcp)
And the compiler would go off and use a combination of concatenation and stringification to produce
#include "../../../components/ip/v1/tcp.h"
and it would include the file and everything would be swell. In gcc 2.95 or so.
Pre-processor behavior is one of those things that is not really completely defined in the C standards (AFAIK.) (Or perhaps it wasn't, and became so.) In any case, sometime before gcc 4.5, the processing order of stringification/concatenation vs #include CHANGED in ways incompatible with the "component" macros, and it all stopped working :-(