I'm trying to cross compile the Azure IoT C SDK. The compilation goes fine for native builds, but when cross compiling I get
[ 33%] Building C object out/uamqp/CMakeFiles/uamqp.dir/src/header_detect_io.c.o
In file included from /home/abertulli/two_lidars/azure-iot-sdk-c/uamqp/inc/azure_uamqp_c/server_protocol_io.h:11:0,
from /home/abertulli/two_lidars/azure-iot-sdk-c/uamqp/src/header_detect_io.c:13:
/opt/box-root-fs/usr/include/stdint.h:266:0: error: "SIZE_MAX" redefined [-Werror]
# define SIZE_MAX (4294967295U)
In file included from /home/abertulli/two_lidars/azure-iot-sdk-c/uamqp/src/header_detect_io.c:11:0:
/home/abertulli/two_lidars/azure-iot-sdk-c/c-utility/inc/azure_c_shared_utility/safe_math.h:8:0: note: this is the location of the previous definition
#define SIZE_MAX ((size_t)((size_t)~(size_t)0))
cc1: all warnings being treated as errors
make[2]: *** [out/uamqp/CMakeFiles/uamqp.dir/build.make:202: out/uamqp/CMakeFiles/uamqp.dir/src/header_detect_io.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:594: out/uamqp/CMakeFiles/uamqp.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
But I see in /opt/box-root-fs/usr/include/stdint.h
(in the sysroot of the compiler)
/* Limit of `size_t' type. */
# if __WORDSIZE == 64
# define SIZE_MAX (18446744073709551615UL)
# else
# ifdef __WORDSIZE32_SIZE_ULONG
# define SIZE_MAX (4294967295UL)
# else
# define SIZE_MAX (4294967295U) // <-------- HERE
# endif
# endif
and in ~/two_lidars/azure-iot-sdk-c/c-utility/inc/azure_c_shared_utility/safe_math.h
#ifndef SIZE_MAX
#define SIZE_MAX ((size_t)((size_t)~(size_t)0)) // <---------- HERE
#endif
Why does it get redefined, even if there is #ifndef
? My guess is that the second file gets compiled first, but why this behaviour shows up only when cross-compiling? And to fix this, should I place a #ifndef
in the sysroot include?
Thanks to everyone for the comments, you helped identifying the problem. It was apparently a problem of misordered/misplaced #include
s in the Azure SDK code. Guarding the #define
in the stdint.h
solved the issue, tho of course it is a temporary workaround, not to be used in production code! In the end, I opened an issue on the Azure repo, where the mantainers kindly and quickly fixed the problem.
EDIT this is the issue, if you are interested in the fix while it's waiting to getting merged