sbc100
commented
1 year ago Yes, I believe clang is able to find its own headers relative to the clang binary.
If you run tjhe compiler (emcc or clang) with -v you can see the internal includes paths being injected when running the internal compile phase:
$ ./emcc -c ~/test//hello.c -v
"/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/clang" --version
"/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/clang" -target wasm32-unknown-emscripten -fignore-exceptions -fvisibility=default -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -DEMSCRIPTEN -Werror=implicit-function-declaration --sysroot=/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -c -v /usr/local/google/home/sbc/test//hello.c -o hello.o
clang version 18.0.0 (https://github.com/sbc100/llvm-project 66c19167f127013f6834ea1a316b783e57490939)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /usr/local/google/home/sbc/dev/wasm/llvm-build/bin
(in-process)
"/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/clang-16" -cc1 -triple wasm32-unknown-emscripten -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -main-file-name hello.c -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/usr/local/google/home/sbc/dev/wasm/emscripten -v -fcoverage-compilation-dir=/usr/local/google/home/sbc/dev/wasm/emscripten -resource-dir /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/18 -D EMSCRIPTEN -isysroot /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot -internal-isystem /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/18/include -internal-isystem /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/wasm32-emscripten -internal-isystem /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include -Werror=implicit-function-declaration -ferror-limit 19 -fvisibility=default -fgnuc-version=4.2.1 -fignore-exceptions -fcolor-diagnostics -iwithsysroot/include/fakesdl -iwithsysroot/include/compat -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o hello.o -x c /usr/local/google/home/sbc/test//hello.c
clang -cc1 version 18.0.0 based upon LLVM 18.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/wasm32-emscripten"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/fakesdl
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include/compat
/usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/18/include
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/include
End of search list.Here you can see that emcc runs clang without /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/18/include anywhere in the command and then then clang -cc1 is internally executed with /usr/local/google/home/sbc/dev/wasm/llvm-build/lib/clang/18/include injected into the include path.
Does your clang build directory not contain lib/clang/18/include?
Here is where that include path gets added in the clang driver: https://github.com/llvm/llvm-project/blob/5082e827c1670f5c98d320d08979b8855253d0cc/clang/lib/Driver/ToolChains/WebAssembly.cpp#L407-L411
Attempting to use SIMD, I get
The root issue here is that I am using a custom script that compiles and bundles Emsdk from source, but that script does not bundle LLVM's wasm_simd128.h header.
So I'd like to fix that, and include the header in our own bundles.
But I am slightly stumped as to where I should place it. I.e. how does LLVM find
wasm_simd128.hto include, when there are no-Idirdirectives that it are passed on the command line?I see in the latest Emscripten precompiled version (
emsdk install latest), there is a directory structurebut when compiling, there is nothing along the lines of
-I<path_to_llvm>/lib/clang/17/include/being said to clang.Does clang.exe have some kind of internal hardcoded
-I../lib/clang/17/include/at play? If I am bundling manually, should I expect to hardcode such a sibling directory path next to whereclang.exelives in? @tlively would you know?