including <net/socket.h> fails with redefinition of 'struct zsock_timeval' (sometimes :-) )

[boaks]

I'm using nRFConnect 1.8.0 and zephyr v2.7.0-ncs1.

If I include <net/socket.h> always as the first, then some files compile well, and some reports

5> In file included from /ncs/zephyr/include/net/socket.h:29,
5> /ncs/zephyr/include/net/socket_select.h:112:17:Kerror: redefinition of 'struct zsock_timeval'
5> In file included from /ncs/zephyr/include/net/socket_select.h:18,
5> from /ncs/zephyr/include/net/socket.h:29,
5> /ncs/zephyr/include/net/socket_types.h:43:8:note: originally defined here

The files are added to the project with

target_sources(app PRIVATE src/a???.c)
target_sources(app PRIVATE src/b???.c)

both file use the same first include

#include <net/socket.h>

For one, it works, for the other it fails. If I remove the failing from the project, the build finishes.
That is very irritating. Has someone similar experience?

[boaks]

I found, that the failing c-file includes <sys/time.h>.

[boaks]

I use now HAVE_SYS_TIME_H in my files to exclude the header.

[gmarull]

may be related #41543

[boaks]

The header <sys/time.h> is part of the compiler tool-chain (gcc-arm-none-eabi-9-2019-q4-major, arm-none-eabi/include/sys). I guess, for other processor families, this may be not the case.
I'm not sure, what fits/fixes best. Either try to exclude the "toolchain headers" or try to include them conditionally. At least it's hard to see, what went wrong, if the compiler includes such header, which are not really supported.
In my case the easiest way was just to "exclude" it within my sources.

[rlubos]

@boaks I've submitted #41916 with my proposal to address the issue.

The core problem was #define timeval zsock_timeval - if the standard header was included after that, the standard struct timeval definition ended up as a redefinition of struct zsock_timeval>

Another thing is that I don't really see a reason for the socket layer to provide its own definition struct zsock_timeval - from what I've seen every libc library we use in Zephyr has this type defined. So in order to fix the issue, I've reused the standard type (struggled a bit with native_posix libc, since it seems to define the type in a different header than newlib or minimal libc) instead of redefining it at the socket layer.

[boaks]

#41916 works for me.

[boaks]

Should I close the issue?

[rlubos]

Should I close the issue?

No need to, GH will close it automatically once the fix is actually merged.