sync with a more appropriate version of the definitions.
as we use the "wasi_ephemeral_nn", which is p1-based, it seems
more appropriate to use definitions from witx, not wit.
it's a bit unfortunate p2-based wasi-nn made gratuitous changes
like this from p1.
note: this is an ABI change.
it seems meaningless and quite confusing to access a table with
two aliases ("lookup" and "backends") within a function.
no functional changes are intended.
```
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
3.14 is used and tested by linux mini-product
to fix
```
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
A recent change on ./product-mini/platforms/linux/CMakeLists.txt renamed
libiwasm to vmlib, but wasi-nn.cmake still wants to link libiwasm.so.
Replace libiwasm with vmlib in wasi-nn.cmake to resolve iwasm build error
when WAMR_BUILD_WASI_NN enabled.
Rust compiler previously deprecated, and now removed the wasm32-wasi target and replaced it with wasm32-wasip1. This
change updates all the occurrences of wasm32-wasi in the context of Rust compilation.
covers the wasi-nn/test.
By default, the project() CMake command defaults to C and C++. [1]
Therefore, CMake might perform tests for both C and C++ compilers as
part of the configuration phase.
However, this has the consequence of the configuration phase to fail if
the system does not have a C++ toolchain installed, even if C++ is not
really used by the top-level project under the default settings.
Some configurations might still require a C++ toolchain, so
enable_language is selectively called under such circumstances.
[1]: https://cmake.org/cmake/help/latest/command/project.html
- For Windows, llvm libs need to cache more directories, so use a multi-line
environment variable for paths
- Remove conditionally build directories `win32build`, just use `build` for all platform
- Add Windows wamrc and iwasm(disable lib pthread semaphore and fast jit for now)
build in release CI
- Clear some compile warnings
- Fix some typos
- Fix llvm LICENSE link error
- Remove unused aot file and binarydump bin
- Add checks when loading AOT exports
The default iwasm building in Windows MSVC enables libc-uvwasi because
libc-wasi isn't supported at the beginning. Since libc-wasi had been refactored
and is supported in Windows msys2 building, and libc-wasi supports more
functionalities(e.g. sockets) than libc-uvwasi, this PR fixes some issues to
enable libc-wasi in windows MSVC buidlings.
As reported in #3500, when debug interpreter is enabled, the classic interpreter
performs a lock operation to read `exec_env->current_status->signal_flag` and
do further handling before fetching next opcode, which makes the interpreter
run slower.
This PR atomic loads the `exec_env->current_status->signal_flag` without mutex
lock when 32-bit atomic load is supported, and only adding lock for further
handling when the signal_flag is WAMR_SIG_SINGSTEP, which improves the
performance.
Fix:
```
wamr/core/iwasm/libraries/libc-builtin/libc_builtin_wrapper.c:20:1:
warning: type of 'wasm_runtime_module_realloc' does not match original declaration [-Wlto-type-mismatch]
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: return value type mismatch
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: type 'uint64' should match type 'uint32'
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: 'wasm_runtime_module_realloc' was previously declared here
wamr/core/iwasm/common/wasm_runtime_common.c:3033:1:
note: code may be misoptimized unless '-fno-strict-aliasing' is used
```
We need to fix numpy version since the latest is incompatible.
> A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.
- All files under *core/iwasm/libraries/wasi-nn* are compiled as shared libraries
- *wasi-nn.c* is shared between backends
- Every backend has a separated shared library
- If wasi-nn feature is enabled, iwasm will depend on shared library libiwasm.so
instead of linking static library libvmlib.a
