wasi sdk
wasi-sdk-24
Téléchargez les packages SDK ici.
Ce référentiel ne contient aucun code de compilateur ou de bibliothèque lui-même ; il utilise des sous-modules git pour extraire l'arborescence Clang et LLVM en amont, ainsi que l'arborescence wasi-libc.
La partie libc de ce SDK est conservée dans wasi-libc.
Upstream Clang et LLVM (à partir de la version 9.0) peuvent être compilés pour WASI dès le départ, et la prise en charge de WebAssembly y est incluse par défaut. Ainsi, tout ce qui est fait ici est de fournir des builds configurés pour définir la cible et la racine système par défaut pour plus de commodité.
On pourrait également utiliser une installation Clang standard, créer un sysroot à partir des sources mentionnées ci-dessus et compiler avec --target=wasm32-wasi --sysroot=/path/to/sysroot . Dans ce scénario, il faudrait également les objets libclang_rt.builtins-wasm32.a disponibles séparément dans les téléchargements de la version qui doivent être extraits dans $CLANG_INSTALL_DIR/$CLANG_VERSION/lib/wasi/ .
Ce référentiel utilise le sous-module git, pour le cloner vous devez utiliser la commande ci-dessous :
git clone --recursive https://github.com/WebAssembly/wasi-sdk.gitLe processus de construction du Wasm-sdk nécessite certains packages :
cmakeclangninjapython3Veuillez vous référer à la documentation de votre système d'exploitation pour installer ces packages.
La construction wasi-sdk utilise CMake et est divisée en deux moitiés. Vous pouvez d’abord créer la chaîne d’outils elle-même :
cmake -G Ninja -B build/toolchain -S . -DWASI_SDK_BUILD_TOOLCHAIN=ON -DCMAKE_INSTALL_PREFIX=build/install
cmake --build build/toolchain --target install Lorsque vous développez localement, vous souhaiterez peut-être également transmettre -DCMAKE_CXX_COMPILER_LAUNCHER=ccache pour faciliter les reconstructions. Les autres indicateurs CMake pris en charge sont :
-DLLVM_CMAKE_FLAGS - indicateurs supplémentaires à transmettre à cmake lors de la construction de LLVM/Clang.-DRUST_TARGET - le triple cible Rust spécifique pour lequel construire wasm-component-ld , utile pour les compilations croisées. Le compilateur clang devrait maintenant se trouver dans build/install/bin/clang mais ce n'est qu'un compilateur, le sysroot n'est pas encore construit. Ensuite, la deuxième étape de la construction consiste à créer la racine système :
cmake -G Ninja -B build/sysroot -S .
-DCMAKE_INSTALL_PREFIX=build/install
-DCMAKE_TOOLCHAIN_FILE=build/install/share/cmake/wasi-sdk.cmake
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
cmake --build build/sysroot --target install Une chaîne d'outils complète devrait maintenant être présente lors de build/install et est prête à être utilisée pour compiler le code WebAssembly. Les indicateurs CMake pris en charge sont :
-DWASI_SDK_DEBUG_PREFIX_MAKE=OFF - désactive -fdebug-prefix-map lors de la construction du code C/C++ pour utiliser à la place les chemins d'accès complets de l'hôte.-DWASI_SDK_INCLUDE_TESTS=ON - utilisé pour créer des tests.-DWASI_SDK_TEST_HOST_TOOLCHAIN=ON - teste les bibliothèques wasi-libc et sysroot de la chaîne d'outils hôte, ne crée pas et n'utilise pas de nouvelles bibliothèques pour les tests.-DWASI_SDK_TARGETS=.. - une liste de cibles à construire, par défaut toutes les cibles WASI sont compilées.-DWASI_SDK_INSTALL_TO_CLANG_RESOURCE_DIR=ON - installe compiler-rt dans le répertoire de ressources du compilateur. cela peut être pratique si vous souhaitez utiliser la chaîne d'outils (par exemple ./build/install/bin/clang ) sur place. Si vous souhaitez créer des artefacts de distribution, vous pouvez utiliser la cible dist comme ceci :
cmake --build build/toolchain --target dist
cmake --build build/sysroot --target dist Les archives tar seront créées sous build/toolchain/dist et build/sysroot/dist . Notez qu'il s'agit d'archives tar distinctes pour la chaîne d'outils et sysroot. Pour créer une seule archive tar pour l'ensemble du SDK, vous devez d'abord copier toutes les archives tar dans un nouveau dossier, puis exécuter le script ./ci/merge-artifacts.sh :
mkdir dist-my-platform
cp build/toolchain/dist/ * build/sysroot/dist/ * dist-my-platform
./ci/merge-artifacts.sh Cela produira dist/wasi-sdk-*.tar.gz qui est le même que les artefacts de version pour ce référentiel.
Enfin, vous pouvez également regrouper bon nombre des étapes ci-dessus, sans merge-artifact.sh en utilisant le script CI pour effectuer à la fois la chaîne d'outils et la construction de sysroot :
./ci/build.sh Le package construit se trouve dans le répertoire build/dist . Pour publier une nouvelle version du package sur GitHub, voir RELEASING.md.
Une installation typique à partir des fichiers binaires de la version pourrait ressembler à ce qui suit :
WASI_OS=linux
WASI_ARCH=x86_64
WASI_VERSION=24
WASI_VERSION_FULL= ${WASI_VERSION} .0
wget https://github.com/WebAssembly/wasi-sdk/releases/download/wasi-sdk- ${WASI_VERSION} /wasi-sdk- ${WASI_VERSION_FULL} - ${WASI_ARCH} - ${WASI_OS} .tar.gz
tar xvf wasi-sdk- ${WASI_VERSION_FULL} - ${WASI_ARCH} - ${WASI_OS} .tar.gz Utilisez le clang installé dans le répertoire wasi-sdk :
WASI_SDK_PATH= ` pwd ` /wasi-sdk- ${WASI_VERSION_FULL} - ${WASI_ARCH} - ${WASI_OS}
CC= " ${WASI_SDK_PATH} /bin/clang --sysroot= ${WASI_SDK_PATH} /share/wasi-sysroot "
$CC foo.c -o foo.wasm Remarque : ${WASI_SDK_PATH}/share/wasi-sysroot contient les inclusions/bibliothèques/etc spécifiques à WASI. L'option --sysroot=... n'est pas nécessaire si WASI_SDK_PATH est /opt/wasi-sdk . Pour le dépannage, on peut remplacer le chemin --sysroot par une construction manuelle de wasi-libc.
Utilisez un fichier de chaîne d'outils pour configurer la plateforme wasi-sdk .
$ cmake -DCMAKE_TOOLCHAIN_FILE=${WASI_SDK_PATH}/share/cmake/wasi-sdk.cmake ...
ou la plateforme wasi-sdk-thread
$ cmake -DCMAKE_TOOLCHAIN_FILE=${WASI_SDK_PATH}/share/cmake/wasi-sdk-pthread.cmake ...
Autoconf 2.70 reconnaît désormais WASI.
Pour plus de commodité lors de la création de packages qui ne sont pas encore mis à jour, les fichiers config.sub et config.guess mis à jour sont installés dans share/misc/config.* dans le répertoire d'installation.
Nous fournissons une image Docker comprenant le SDK WASI qui peut être utilisée pour créer des projets sans installation séparée du SDK. Autotools, CMake et Ninja sont inclus dans cette image, et les variables d'environnement standard sont définies pour utiliser le SDK WASI pour la construction.
Par exemple, cette commande peut créer un projet basé sur make avec l'image Docker.
docker run -v `pwd`:/src -w /src ghcr.io/webassembly/wasi-sdk make
Prenez note des limitations notables ci-dessous lors de la création de projets. Par exemple, de nombreux projets nécessiteront que la prise en charge des threads soit désactivée lors d'une étape de configuration avant la création avec le SDK WASI.
Ce référentiel ne prend pas encore en charge les exceptions C++ . Le code C++ est pris en charge uniquement avec les exceptions -fno pour le moment. Des travaux sur la prise en charge de la gestion des exceptions sont en cours au niveau du langage qui prendra en charge les fonctionnalités.
Voir Prise en charge de C setjmp/longjmp à propos de la prise en charge de setjmp/longjmp.
Ce référentiel prend en charge expérimentalement les threads avec --target=wasm32-wasi-threads . Il utilise les primitives de threads de WebAssembly (atomique, wait / notify , mémoire partagée) et les wasi-threads pour la génération de threads. Remarque : ceci est expérimental — ne vous attendez pas à une stabilité à long terme !
Ce référentiel ne prend pas encore en charge les bibliothèques dynamiques . Bien qu'il y ait quelques efforts pour concevoir un système de bibliothèques dynamiques dans wasm, il est encore en développement et n'est pas encore généralement utilisable.
Il n'y a aucun support pour la mise en réseau . L'un des objectifs de WASI est cependant de soutenir la mise en réseau à l'avenir.
