search

KhronosGroup / glslang

Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.
Other
2.9k stars 815 forks source link

Fix compilation for WASI target #3633

Closed antaalt closed 4 days ago

antaalt commented 1 week ago

I was looking into compiling glslang for WASM WASI target, and I successfully did so by removing some reference to threads as WASI does not support threads yet. So here is a small PR that disable thread safety in order to allow compilation for WASI, the preprocessor guarding is safe so this should not impact anything other than WASI target.

arcady-lunarg commented 6 days ago

Is this the complete set of changes needed? I also see uses of the <mutex> header in SPIRV/doc.cpp and StandAlone/Worklist.h. Would you mind sharing instructions as to how you went about building for WASI?

antaalt commented 6 days ago

On my side, it was enough to compile, the <mutex> header does not seems to be an issue, but I might add it to the preprocessor aswell to be sure.

For the compilation, I went with glslang-rs which is a rust wrapper for glslang, and build c++ bindings using a build.rs file and cc-rs. It is fairly simple, just listing all the files to build and linking them. I did not looked into CMakeList because WASI does not look supported yet, but maybe it could be added to the build system, which require clang with a sysroot retrieved from WASI SDK (wasi preprocessor should only be defined in clang targeting wasi, which is the only compiler supporting wasi right now).

antaalt commented 6 days ago

For the background, I am trying to compile it to WASI because vscode now support running WASI module and I was trying to have a linter extension with glslang directly embedded into the extension, it is working nicely but require these few adjustments to compile.