EDIT:
To Be Clear: If the order of your #includes matters and it is not part of your design pattern (read: you don't know why), then you need to rethink your design. Most likely, this just means you need to add the #include to the header file causing problems.
At this point, I have little interest in discussing/defending the merits of the example but will leave it up as it illustrates some nuances in the compilation process and why they result in errors.
END EDIT
You need to #include the stdint.h BEFORE you #include any other library interfaces that need it.
Example:
My LCD library uses uint8_t types. I wrote my library with an interface (Display.h) and an implementation (Display.c)
In display.c, I have the following includes.
#include <stdint.h>
#include <string.h>
#include <avr/io.h>
#include <Display.h>
#include <GlobalTime.h>
And this works.
However, if I re-arrange them like so:
#include <string.h>
#include <avr/io.h>
#include <Display.h>
#include <GlobalTime.h>
#include <stdint.h>
I get the error you describe. This is because Display.h needs things from stdint.h but can't access it because that information is compiled AFTER Display.h is compiled.
So move stdint.h above any library that need it and you shouldn't get the error anymore.
To use uint8_t type alias, you have to include stdint.h standard header.
I had to include "PROJECT_NAME/osdep.h" and that includes the os specific configurations.
I would look in other files using the types you are interested in and find where/how they are defined (by looking at includes).
Source: Stackoverflow.com