I am trying to cross-compile with arm-none-eabi-gcc-9.2.x and had the following problem:
undefined symbol 'PRIu64'
(message shortened to necessary minimum by me) which was caused by the Newlib header inttypes.h doing a:
#include <stdint.h>
which motivated gcc to include its onboard stdint.h from
/usr/lib/gcc/arm-none-eabi/9.2.1/include
instead of the Newlib one in
/usr/include/newlib
thereby breaking the compilation with the above error. Of course I first tried to prefix the include path search with the usual
arm-none-eabi-gcc-9.2.1 -I/usr/include/newlib ...
but to my big surprise gcc spew it back at me (via -xc -E -v) with:
ignoring duplicate directory "/usr/include/newlib"
as it is a non-system directory that duplicates a system directory
Only a
arm-none-eabi-gcc-9.2.1 -isystem /usr/include/newlib ...
convinced it to include the Newlib directory in its search.
Is this due to a broken installation? And how dare gcc to not include a path I am supplying?
Do the ARM people ship their gcc with both, Newlib and a set of vanilla gcc system headers or where did this misconfiguration come from?
Indeed, newlib provides <stdint.h> while gcc also provides it. So, when <inttypes.h> includes <stdint.h> it does not include <stdint.h> from newlib but the one from gcc. It wouldn't be a big deal if <stdint.h> wouldn't define some macro used internally by <inttypes.h>.
The best thing to do is to fix newlib, change your compiler or patch your system headers.
If it is not possible you can include <sys/types.h> before <inttypes.h>. <sys/types.h> includes <_stdint.h> that define the necessary macros.
It seems the problem is specific to arm-none-gcc provided by Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953844