alexcrichton wrote: Currently it accepts no extra inputs, but in the future I'd expect that it'll grow an option or two of its own. Currently it [hand-codes the list of options to forward to `wasm-ld`](https://github.com/alexcrichton/wasm-component-ld/blob/2f6106e395e2db99a8bb0524088d08bb6964997a/src/main.rs#L23-L53) which I'm sure will need updates over time, but that should be ok. And yes, the purpose of `wasm-component-ld` is twofold:
1. First it invokes `wasm-ld` internally, producing the core wasm that's expected today. 2. Next it invokes the "componentization process" which activates some Rust crates that converts this output core wasm module into a component. In step (2) it's using component type information smuggled through LLVM/wasm-ld through custom sections to create the final output component. > Do we expect clang users to be building compound components using a single > clang command? If by compound you mean linking multiple components internally, then no. The intention is that `wasm32-wasip2` outputs a component but internally it's "just" a core wasm module. The next phase of composing components together we've got other tooling for, and that's intended to be outside the scope of individual language toolchains. (e.g. in theory composition works the same regardless of source language) > Would it make more sense to have clang default to building core modules and > have the component creation be a higher level thing built on top clang > outputs? That's actually what we currently have to day with converting `wasm32-wasip1` outputs into components. The purpose of `wasm32-wasip2`, however, is that core wasms are not natively usable as-is because WASI APIs are defined at the level of the component model, not core wasm. There is of course definitions for core wasm using the canonical ABI, but that's not the focus of WASI nowdays. I do plan on having a flag (also answering the question about wasm-component-ld-specific-flags) to not emit a component and instead skip the componentization step. This step could also be done by using `-fuse-ld=wasm-ld` (or the equivalent thereof) to just switch the default linker back to `wasm-ld`. > Regarding WebAssembly/wasi-sdk and WebAssembly/wasi-libc, is there any reason > why simple programs wouldn't be core modules? Won't most C/C++ programs still > be build-able as just core modules? Yep, they'll all still be buildable as core modules (as that's the internals of a component anyway, a big thing produced by LLVM). With the p2 target though the thinking is that components are the default output, not core wasm modules. --- Another future feature on the theoretical roadmap for wasm-component-ld is that Joel has componentize-py built on "dynamic linking" of a sort which gets `dlopen` working enough for Python to open its native extensions. This is all built on the Emscripten dynamic linking model and a component packages that all up into a single component where the dynamic libraries are statically known at build time. This is all wrapped up in `wasm-tools component link` and is something I'd like to also automatically bake in to `wasm-component-ld` so building that style of component is much easier. https://github.com/llvm/llvm-project/pull/84569 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
