The mess with include paths

I've got some weird situation going with uint64_t being defined by two
headers.  It seems to happen because the library I'm working with
is supposed to be used on 'bare metal', and I think we have a mess with
cross compilers.

I still have to build some confidence on the topic.  This requires to spend
some good hour in reading up documentation, possibly after some proper sleep
(doing all this with a toddler who wakes up 2 to 3 times per night does *NOT*
help).

Follows some info I've collected on my path, mentioned by colleagues,
and found on the Internet.  I should investigate more before I can tell
I know the topic inside out.


1. The compiler has some built-in defaults

Include paths, standard library, sysroots.  Probably more.
They are set upon compilation (of the compiler) and can be overriden
upon invocation.


2. Default include paths can be exhamined like this:

$CC -Wp,-v -E - </dev/null

    -Wp,-v         tells the compiler to pass -v to the pre-processor
           -E      tells to stop after pre-processing
	      -    tells to take the code from stdin, here /dev/null

As output I can see where headers are taken from.


3. Prevent the access to standard headers

$CC -nostdinc

And -nostdinc++ if using C++, which is fortunately not the case.


4. Specify explicit system includes with -isystem

Interestingly, you can use the '=' prefix, that is expanded with the sysroot


5. Conclusion:

I want gcc to only honour the headers in its sysroot.  Everything boils down
to provide gcc with this with the CFLAGS:

-isystem =/usr/include

Hint: the compiler driver will print the sysroot (that is what is going to be
expanded in place of '=') when invoked like this:

$CC -print-sysroot