zephyr: include libc utils when building with WASI support

[hasheddan]

Follows up the change in
#2585 to include libc utils when targeting zephyr, which abstracts posix filesystem functions.

Fixes #2846 (there may be subsequent issues that need to be addressed regarding WASI support on Zephyr)

[salva00]

I have tried to fix the issue manually by modifying the shared_platform.cmakewith your commit addition but it persisted #2846 error :(

PS: I'm building with west build . -b qemu_cortex_a53 -p always -- -DWAMR_BUILD_LIBC_WASI=1 -DWAMR_BUILD_LIB_WASI_THREADS=1 -DWAMR_BUILD_TARGET=AARCH64

[hasheddan]

@salva00 thanks for reporting! Could you share your build logs?

[salva00]

@hasheddan Sure! This is my build log:
build_log.txt

[hasheddan]

@salva00 thanks! It appears that this PR does solve the inclusion of libc_errno.h, but there are additional errors that follow it.

[zoraaver]

Hi, I'm not really familiar with zephyr and whether it is POSIX compliant or not. If it is, it should be a matter of adding the missing headers to platform_internal.h to fix these build errors. Otherwise, you would need to implement the filesystem APIs for zephyr.

[lucasAbadFr]

Hello, any news on this issue ?

Zephyr File System API is not POSIX compliant, so I think it's a bad idea to include posix_file.c. Also Zephyr is a RTOS so it doesn't necessarily comes with a FS (I never tried to use one).

But Zephyr implement it's own socket stack, which will requiere WAMR_BUILD_LIBC_WASI=1.

If I understand correctly, the first issue lies in the sandboxed-system-primitives and because in Zephyr:

• struct timespec doesn't exist
• struct pollfd doesn't exist
• type nfds_t doesn't exist

I think that this issue is not limited to Zephyr but apply to most RTOS (freeRTOS, RIOT, ...)

Should we do like with windows and abstract these concepts (at the OS level) ?

@zoraaver What is your opinion on this ?

[zoraaver]

Hi @lucasAbadFr,

Zephyr File System API is not POSIX compliant, so I think it's a bad idea to include posix_file.c. Also Zephyr is a RTOS so it doesn't necessarily comes with a FS (I never tried to use one).

That sounds fine to me, although it seems Zephyr does have a filesytem API -https://docs.zephyrproject.org/latest/services/file_system/index.html? If you just want socket support, you could just stub the filesystem functions (which it looks like you've done in #3335). Either way, you probably don't want to include posix_file.c if Zephyr does not provide the actual POSIX file APIs.

• struct timespec doesn't exist
• struct pollfd doesn't exist
• type nfds_t doesn't exist

I think it's fine to abstract these types, similar to how we did for os_file_handle. These structures weren't an issue for Windows because we didn't need poll support for our use case so we just ifdeffed them out in posix.c. If you want poll support, I guess you'll have to abstract poll and implement it for Zephyr. Otherwise, you could alter the ifdef's in posix.c so that the code is not compiled for Zephyr (obviously you won't have poll support in Zephyr then).

The best option in either case depends on your needs i.e. whether you need filesystem support or poll support in Zephyr.

I hope that's helpful. Let me know if anything is unclear.