arm cross compilation - bad include path
Checking the compilation of MR !2590 (merged), for cross-compilation for ARM I saw a lot of warnings of this kind:
[676/11256] Building C object CMakeFiles/PHY_UE.dir/openair1/PHY/LTE_UE_TRANSPORT/sss_ue.c.o
In file included from ../../../common/config/config_load_configmodule.h:42,
from ../../../common/config/config_userapi.h:35,
from ../../../radio/COMMON/record_player.h:34,
from ../../../radio/COMMON/common_lib.h:39,
from ../../../openair1/PHY/defs_UE.h:57,
from ../../../openair1/PHY/LTE_UE_TRANSPORT/sss_ue.c:32:
../../../openair1/PHY/defs_common.h: In function 'wakeup_thread':
../../../common/utils/T/T.h:135:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
135 | #define T_ACTIVE(x) T_active[(intptr_t)x]
| ^
../../../common/utils/T/T.h:230:9: note: in expansion of macro 'T_ACTIVE'
230 | if (T_ACTIVE(t)) { \
| ^~~~~~~~
../../../common/utils/T/T.h:102:81: note: in expansion of macro 'T3'
102 | n18,n19,n20,n21,n22,n23,n24,n25,n26,n27,n28,n29,n30,n31,n32,n,...) T##n
| ^
../../../common/utils/T/T.h:99:17: note: in expansion of macro 'TN_N'
99 | #define TN(...) TN_N(__VA_ARGS__,33,32,31,30,29,28,27,26,25,24,23,22,21,\
| ^~~~
../../../common/utils/T/T.h:103:57: note: in expansion of macro 'TN'
103 | #define T(...) do { if (T_stdout == 0 || T_stdout == 2) TN(__VA_ARGS__); } while (0)
| ^~
../../../common/utils/LOG/log.h:399:33: note: in expansion of macro 'T'
399 | # define LOG_E(c, x...) do { T(T_LEGACY_ ## c ## _ERROR, T_PRINTF(x)) ; if (T_stdout) { if( g_log->log_component[c].level >= OAILOG_ERR ) logRecord_mt(__FILE__, __FUNCTION__, __LINE__,c, OAILOG_ERR, x) ;} } while (0)
| ^
../../../openair1/PHY/defs_common.h:1096:5: note: in expansion of macro 'LOG_E'
1096 | LOG_E( PHY, "ERROR pthread_cond_signal\n");
| ^~~~~
Digging deeper, reproducing the compilation on my machine, I found out that the option -I /usr/include/x86_64-linux-gnu
is added to the command line of the cross compiler. When I remove it, the warnings go away.
Comparing the outputs of gcc -E (to see what the C pre-processor does) with and without this option, I see those differences:
173c175
< __extension__ typedef int __intptr_t;
---
> typedef long int __intptr_t;
And:
< typedef unsigned int uintptr_t;
<
<
<
<
---
> typedef unsigned long int uint_fast16_t;
> typedef unsigned long int uint_fast32_t;
> typedef unsigned long int uint_fast64_t;
> # 90 "/usr/aarch64-linux-gnu/include/stdint.h" 3 4
> typedef unsigned long int uintptr_t;
So we have a clear difference in the definition of intptr_t
and intptr_t
with and without this -I.
So we should not have this -I when compiling for ARM I think.
Looking inside CMakeCache.txt
I see:
[...]
blas_STATIC_CFLAGS:INTERNAL=-I/usr/include/x86_64-linux-gnu
[...]
lapacke_STATIC_CFLAGS:INTERNAL=-I/usr/include/x86_64-linux-gnu
[...]
So this -I
may come from blas/lapacke (but I'm not sure).
For the T tracer, I think those warnings are not a problem. We cast an int to a pointer to an int again, so I don't think it will create a bad behavior. We are just flooded with compilation warnings. If needed I can try to "fix" the T tracer to remove them, but I think it would not be a correct solution. The correct solution is to not have -I /usr/include/x86_64-linux-gnu
when we compile for ARM.
I see some similar warnings for other source files, which may or not be a real problem though.
I don't know exactly how to solve this problem. Open to suggestions.