[Bug] Build breaks on Zephyr RTOS v3.4.0

[entire]

Describe the bug

Seems like there was a change that breaks zenoh-pico/src/system/zephyr/network.c in the network interface APIs, since Zephyr v3.4.0 (https://docs.zephyrproject.org/latest/releases/release-notes-3.4.html) it now takes additional, struct net_if * iface parameter:

:c:func:net_if_ipv4_maddr_join
:c:func:net_if_ipv4_maddr_leave
:c:func:net_if_ipv6_maddr_join
:c:func:net_if_ipv6_maddr_leave

It works with Zephyr RTOS v3.3.0 before the change was made.

To reproduce

• Fresh build from the 9b663d5 commit
• Build with Zephyr RTOS v3.4.0 tag or later
• ran west init && west build locally, followed https://github.com/cguimaraes/zenoh-pico-zephyr-example example

System info

• MacOS 13.3.1 Ventura (Mac M1)
• Zephyr RTOS v3.4.0
• Zenoh-pico 0.7.2

[cguimaraes]

Thanks for reporting it.
At this point, we shall support:

• Zephyr 2(.7.0+) as the LTS release
• Zephyr 3.3.0 and below
• Zephyr 3.4.0 and above

@entire Do you know if there is any Zephyr environment variable that can be used at compile time to identify the version?

[bryceschober]

@cguimaraes See https://docs.zephyrproject.org/latest/doxygen/html/kernel__version_8h.html

[bryceschober]

@cguimaraes It looks like the low-level "interface" is to #include "versio.h", whose contents are generated by (and documented in) the version.cmake file (2.7, 3.3-main).

[cguimaraes]

Thank you @bryceschober for the input. It was very helpful to improve the Zephyr version detection within Zenoh-Pico.

There is a partial fix for this issue, until the new Zephyr multicast API is integrated: #230

@entire if this is a blocking point for you but you do not need Zenoh multicast transport, you might want to set Z_LINK_UDP_MULTICAST to 0.

[cguimaraes]

#230 contains now a complete fix for it.
Missing proper testing before merging.

@entire could you help us testing it on your setup?

[entire]

seems to work, thanks! @cguimaraes