zephyr: The `simple-file` and `simple-http` samples don't compile.

[lucasAbadFr]

Subject of the issue

The simple-file and simple-http Zephyr samples fail to compile on current main.
Both samples were originally introduced to demonstrate WASI libc support on Zephyr, but they are now broken due to missing includes and undeclared functions in the Zephyr platform layer.

Your environment

• Host OS: Ubuntu 22.04
• WAMR: current main
• Zephyr: v3.7.0 (LTS)
• Platform: Zephyr
• CPU arch: ARM Cortex-M (tested on frdm_mcxn947/mcxn947)

Steps to reproduce

Simply follow the sample readme.

Expected behavior

Both samples should compile and run.

Actual behavior

Compilation fails with errors such as:

error: invalid use of incomplete typedef 'os_timespec' {aka 'struct timespec'}
error: storage size of 'ts' isn't known
warning: implicit declaration of function 'nanosleep' [-Wimplicit-function-declaration]
error: storage size of 'ts' isn't known

Extra info

The root cause is that os_timespec is only forward-declared as struct timespec, which is not defined in Zephyr unless CONFIG_POSIX_API=y.
However, the Zephyr port of WAMR is intended to work without enabling the POSIX API.
As a result, the samples cannot currently build against Zephyr v3.7 LTS.

I plan to submit a PR to fix this issue.

[anasimran101]

@lucasAbadFr
so whats the status? I have been trying to build this sample-file and test libc-wasi on zephyr. I am using zephyr v4.2.0

building the sample simple with revision to main branch gives:

/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/shared/platform/zephyr/platform_internal.h:253:26: error: field 'file' has incomplete type
253 | struct fs_file_t file;

WAMR_BUILD_LIBC_WASI is set to 0 or 1 doesnt matter.

Build is a success when i use WAMR-2.4.x with WAMR_BUILD_LIBC_WASI set to 0.
if i try to set it to WAMR_BUILD_LIBC_WASI to 1, it spits out a long list of build error top one being:

/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/blocking_op.h:60:65: error: unknown type name 'nfds_t'
60 | blocking_op_poll(wasm_exec_env_t exec_env, struct pollfd *pfds, nfds_t nfds,
| ^~~~~~
/workdir/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/blocking_op.c:10:10: fatal error: libc_errno.h: No such file or directory

so what i understand is that attempts to fix the libc_errno.h issue and other were made and work done was added to main branch as the simple-file is not in WAMR-2.4.x

But why does revision to main branch spits out
field 'file' has incomplete type
253 | struct fs_file_t file;

My apologies if i sound dumb. I am new to this kind of thing

[lucasAbadFr]

@anasimran101
No problem, no questions ever sound dumb.

---

About the status:

I proposed a fix to solve the problem see the revelant PR: #4629

Some context that can be useful:

The increased support for Zephyr and the effort to support WAMR_BUILD_LIBC_WASI began last year or earlier and was inside a branch for close to a year but was recently merge in #4347. So it is expected that it fails with WAMR v4.20 because it is simply not supported. Your intuition was right.

Now back to main, the samples should work, but they don't due to compilation issues. This may be due to two factors:

• The contributors may have another branch that is ahead of WAMR and not yet proposed.
• The lack of Zephyr checks on CI which are known and people are working on it.

Anyways having it merged on main is great.

Your questions

Incomplete type: (on main)

/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/shared/platform/zephyr/platform_internal.h:253:26: error: field 'file' has incomplete type
253 | struct fs_file_t file;

It is due to a missing include in zephyr platform_internal.h. Simply #include <zephyr/fs/fs.h> to fix this error.

Unknown type (on v4.20)

/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/blocking_op.h:60:65: error: unknown type name 'nfds_t'
60 | blocking_op_poll(wasm_exec_env_t exec_env, struct pollfd *pfds, nfds_t nfds,
| ^~~~~~
/workdir/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/iwasm/libraries/libc-wasi/sandboxed-system-primitives/src/blocking_op.c:10:10: fatal error: libc_errno.h: No such file or directory

This is part of the work that has been done to support a WAMR_BUILD_LIBC_WASI build. If you want some context on why it appears look at #3311 and #3633 which was the beginning of the work. For further understanding you can also look at all the APIs we go through to have a WASI p1 or custom API call go from the WASM module to the host (begin by folder sandboxed-system-primitives and wasmtime_ssp.h).

libc_errno.h (on v4.20)

so what i understand is that attempts to fix the libc_errno.h issue and other were made and work done was added to main branch as the simple-file is not in WAMR-2.4.x

As I said before yout intuition is right, some work as indeed been done after WAMR-2.4.x.
But it has close to nothing to do with libc_errno.h, it is also an include problem and this file simply introduce a way to convert a POSIX error code to a WASI error code (__wasi_errno_t)

Conclusion

If you want to test the samples use #4629

---

I hope to have answered your questions.

[anasimran101]

Thanks a lot for the reply @lucasAbadFr

Yesterday I did add the #include <zephyr/fs/fs.h> header in /workdir/zephyr/zephyr-base/modules/lib/wasm-micro-runtime/core/shared/platform/zephyr/zephyr_file.c after posting this comment hehe

I think there was also some undefined ref to bh_strdup which was also resolved by including the relevant header

Then there were linker errors for nanosleep which disappeared when i woke up this morning. I think there was a merge to fix those

So The build succeeded on zephyr 4.2.x

Now i am having some issues with linear memory while instantiating the module which i will look into next. But yeah finally it builds without issues on the latest version of zephyr after these small header inclusions

Again thanks a lot