#include <inttypes.h> not found

[mjbcswitzerland]

Hi All

I have a project that uses some middle-ware code with

#include <inttypes.h>

which doesn't build with MCUXpresso since this header is not found. Previously with KDS there was no problem.

Also, I can build the project from a make file with the same compiler as used by MCUXpresso.

In the same file there are other such headers, such as
#include <string.h>

which cause no problems.

In fact, when I search for inttypes.h on the PC I find it in the same folder as string.h.
"MCUXpressoIDE_10.2.1_795\ide\tools\arm-none-eabi\include"

How can one header be found but the other not? Are specific include paths needed, and where are they located in MCUXpresso?

Thanks in advance!

Regards

Mark

[ErichStyger · Accepted solution]

Hi Mark,

It seems to me that you are using RedLib?

In that library the inttypes are not supported as it is a reduced set of library functions.

Instead, use the newlib or newlib nano:

I hope this helps,

Erich

[mjbcswitzerland]

Eric

Yes, I have always used REDLIB setting although I don't think that I really use anything from it.

In fact the only thing needed was a typedef for uint_32t so I changed to NewlibNano (none) and now it finds the header.

The binary generated is identical in both cases so I'll stick with NewlibNano (none) for the moment so that this header is not missing.

Thanks since I would have had no idea what could have led to this.

When I build from a make file (the usual method since opening MCUXpresso to build is excruciatingly slow) I don't specify any particular library so it must be using a default one. It's binary is in fact a few bytes larger in size but this may also be due to it linking files in a different sequence any leaving some holes when aligning (or similar).

Regards

Mark

[ErichStyger]

Hi Mark,

a better and more portable way is to use

#include <stdint.h>‍

I hope this helps,

Erich

[JBM]

I know this is a bit old, but including <stdint.h> doesn't get the macros in inttypes.h (or doesn't seem to).  

[mjbcswitzerland]

Eric

The include is in some standard mbed TLS code so I don't want to change things there otherwise it will be overwritten when updating libraries in the future (and the fix will need to be made again - but no one will remember what was done anymore this post was found again....;-). Library change is probably more future-proof.

Regards

Mark