Created
December 15, 2023 04:32
-
-
Save anutosh491/09eadc6dc12d88115c4d70ba6250b63c to your computer and use it in GitHub Desktop.
Serge breakdown
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So I've made enough progress and I currently have enough understanding of what's | |
happening to share it with you. I can't invest more time on this than what I've | |
already be doing, hopefully this is going to put you on track. | |
= Why do we have this -isystem /usr/include? | |
emcmake passes a toolchain file (cmake/Modules/Platform/Emscripten.cmake) to | |
cmake that informs it about the toolchain. In the process it sets | |
CMAKE_CROSSCOMPILING=ON. | |
During llvm build process, if CMAKE_CROSSCOMPILING=ON, then a sub build of llvm | |
happens, a "native" build, to build the native tools needed to bootstrap the | |
compiler. Mostly llvm-tblgen and clang-tblgen, but they are not the only ones. | |
the configure step for this "native" build is confused by all the environment | |
variables set by emcmake, which leads to invalid decision. In particular it does | |
detect some zlib.h and zstd.h headers in the system (in /usr/include) and tries | |
to use them. But has it still using em++, or maybe because of some env variable, | |
this native build keeps on trying to generate wasm (!). | |
So one way to get rid of these extra header is to force the "native build" not | |
to look for zlib or zstd. The following patch does so (it also replaces em++ by | |
clang++ to prevent some of the side effects mentionned above): | |
patch -p1 << EOF | |
--- ./llvm/cmake/modules/CrossCompile.cmake 2023-12-14 10:22:34.750923364 | |
0100 | |
+++ ./llvm/cmake/modules/CrossCompile.cmake2 2023-12-14 10:59:55.217196320 | |
0100 | |
@@ -70,8 +70,10 @@ | |
add_custom_command(OUTPUT | |
\${\${project_name}_\${target_name}_BUILD}/CMakeCache.txt | |
COMMAND \${CMAKE_COMMAND} -G "\${CMAKE_GENERATOR}" | |
-DCMAKE_MAKE_PROGRAM="\${CMAKE_MAKE_PROGRAM}" | |
- -DCMAKE_C_COMPILER_LAUNCHER="\${CMAKE_C_COMPILER_LAUNCHER}" | |
- -DCMAKE_CXX_COMPILER_LAUNCHER="\${CMAKE_CXX_COMPILER_LAUNCHER}" | |
+ -DCMAKE_C_COMPILER="clang" | |
+ -DCMAKE_CXX_COMPILER="clang++" | |
+ -DLLVM_ENABLE_ZLIB="\${LLVM_ENABLE_ZLIB}" | |
+ -DLLVM_ENABLE_ZSTD="\${LLVM_ENABLE_ZSTD}" | |
\${CROSS_TOOLCHAIN_FLAGS_\${target_name}} \${CMAKE_CURRENT_SOURCE_DIR} | |
\${CROSS_TOOLCHAIN_FLAGS_\${project_name}_\${target_name}} | |
EOF | |
while passing | |
-DLLVM_ENABLE_ZSTD=OFF \ | |
-DLLVM_ENABLE_ZLIB=OFF \ | |
If I understand correctly, forcing the compiler to be clang should be enough, no | |
need to hack LLVM_ENABLE_ZSTD, I'm just sharing the different steps I've been | |
exploring. | |
It is however, not enough, but certainly a track to follow. | |
Another approach that led me to a final clang.js (\o/) is to skip the "native | |
build" step. This can be done either through modification of the | |
cmake/Modules/Platform/Emscripten.cmake file or (and that's what I did) a small | |
patch: | |
patch -p1 << EOF | |
--- llvm/CMakeLists.txt 2023-12-14 14:32:34.608021529 +0100 | |
+++ llvm/CMakeLists.txt2 2023-12-14 14:32:25.722915506 +0100 | |
@@ -762,6 +762,7 @@ | |
message(FATAL_ERROR "Cannot enable BUILD_SHARED_LIBS with LLVM_LINK_LLVM_DYLIB. We recommend disabling BUILD_SHARED_LIBS.") | |
endif() | |
+set(CMAKE_CROSSCOMPILING OFF) | |
option(LLVM_OPTIMIZED_TABLEGEN "Force TableGen to be built with optimization" OFF) | |
if(CMAKE_CROSSCOMPILING OR (LLVM_OPTIMIZED_TABLEGEN AND (LLVM_ENABLE_ASSERTIONS OR CMAKE_CONFIGURATION_TYPES))) | |
set(LLVM_USE_HOST_TOOLS ON) | |
EOF | |
if you do so, you need to provide your own version of the bootstrapped tool. I | |
did this by recompiling llvm locally to get llvm-tblgen and clang-tblgen, then | |
passed | |
-DLLVM_TABLEGEN=$HOME/sources/llvm-project/_build/bin/llvm-tblgen \ | |
-DCLANG_TABLEGEN=$HOME/sources/llvm-project/_build/bin/clang-tblgen | |
with these changes I've been able to build clang.js, but not the install step, | |
as clang-ast-dump is another missing tool that needs to be compiled natively and | |
passed to LLVM, but there's no variable to do so. It would be easy to craft a | |
patch to do so though. | |
Again, sorry for not "finishing" the job, but I've used more than the time | |
credit I wanted to allocate to this. Hopefully this long wall of text will help you. | |
Serge |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment