[PATCH] D130788: [clang-repl] Disable building when LLVM_STATIC_LINK_CXX_STDLIB is ON.

Fri Aug 19 06:14:02 PDT 2022

sunho added a comment.

In D130788#3732325 <https://reviews.llvm.org/D130788#3732325>, @sbc100 wrote:

> In D130788#3731232 <https://reviews.llvm.org/D130788#3731232>, @sunho wrote:
>
>> In D130788#3730533 <https://reviews.llvm.org/D130788#3730533>, @sbc100 wrote:
>>
>>> I'm not totally sure but I think the change is responsible for the emscripten integration bot failing `InterpreterTest.CatchException`: https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8807160007692150337/+/u/LLVM_regression/stdout
>>>
>>>   [==========] Running 1 test from 1 test suite.
>>>   [----------] Global test environment set-up.
>>>   [----------] 1 test from InterpreterTest
>>>   [ RUN      ] InterpreterTest.CatchException
>>>   JIT session error: Symbols not found: [ __gxx_personality_v0, _ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_throw ]
>>>   Failure value returned from cantFail wrapped call
>>>   Failed to materialize symbols: { (main, { _ZN16custom_exceptionC2EPKc, __clang_call_terminate, _ZTI16custom_exception, _ZTS16custom_exception, throw_exception }) }
>>>   UNREACHABLE executed at /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/include/llvm/Support/Error.h:786!
>>>   Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x2464413)[0x55cb14660413]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246236c)[0x55cb1465e36c]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x24648df)[0x55cb146608df]
>>>   /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fad2fab1980]
>>>   /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fad2eb0de87]
>>>   /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fad2eb0f7f1]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x23f798f)[0x55cb145f398f]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9de35)[0x55cb14099e35]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9d597)[0x55cb14099597]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246d6be)[0x55cb146696be]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246e659)[0x55cb1466a659]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246ee40)[0x55cb1466ae40]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x247b2c3)[0x55cb146772c3]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x247ab42)[0x55cb14676b42]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x246559c)[0x55cb1466159c]
>>>   /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fad2eaf0c87]
>>>   /b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests(+0x1e9ceda)[0x55cb14098eda]
>>>
>>> This started happening consistently after this change https://chromium.googlesource.com/emscripten-releases/+/584b2f531314d1e70cd5ebadcce7e015a6215c9a.  The only CL in that list that looks related seems to be this one.
>>
>> Could you share the detailed build configuration of those bots?
>
> All the step should be visible here: https://ci.chromium.org/ui/p/emscripten-releases/builders/ci/linux-test-suites/b8805531315340503553/steps
>
> The most relevant one I guess would be:
>
> https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8805531315340503553/+/u/Build_LLVM/stdout
>
> Here you can see LLVM being configured with:
>
>   subprocess.check_call(`/b/s/w/ir/cache/builder/emscripten-releases/cmake-3.21.3-linux-x86_64/bin/cmake -G Ninja -DPython3_EXECUTABLE=/b/s/w/ir/cache/vpython/68bda9/bin/python -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/b/s/w/ir/x/w/install -DCMAKE_CXX_FLAGS=-stdlib++-isystem/b/s/w/ir/x/w/install/include/c++/v1 "-DCMAKE_EXE_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" "-DCMAKE_SHARED_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" "-DCMAKE_MODULE_LINKER_FLAGS=-L/b/s/w/ir/x/w/install/lib -stdlib=libc++" -DCMAKE_SYSROOT=/b/s/w/ir/cache/builder/emscripten-releases/sysroot_debian_stretch_amd64 -DCMAKE_C_COMPILER=/b/s/w/ir/cache/builder/v8/third_party/llvm-build/Release+Asserts/bin/clang -DCMAKE_CXX_COMPILER=/b/s/w/ir/cache/builder/v8/third_party/llvm-build/Release+Asserts/bin/clang++ -DCMAKE_C_COMPILER_LAUNCHER=/b/s/w/ir/cache/goma/client/gomacc -DCMAKE_CXX_COMPILER_LAUNCHER=/b/s/w/ir/cache/goma/client/gomacc /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_BUILD_LLVM_DYLIB=OFF -DLLVM_LINK_LLVM_DYLIB=OFF -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DLLVM_ENABLE_BINDINGS=OFF -DLLVM_TOOL_LTO_BUILD=OFF -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON -DLLVM_TARGETS_TO_BUILD=host;WebAssembly -DLLVM_ENABLE_PROJECTS=lld;clang -DLLVM_ENABLE_TERMINFO=0 -DLLVM_USE_CRT_RELEASE=MT -DLLVM_USE_CRT_DEBUG=MTd -DCLANG_ENABLE_ARCMT=OFF -DCLANG_ENABLE_STATIC_ANALYZER=OFF -DCLANG_REPOSITORY_STRING=https://github.com/llvm/llvm-project -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_ASSERTIONS=ON`, cwd=`/b/s/w/ir/cache/builder/emscripten-releases/build/llvm-out`)
>
> The code the drives the build is here: https://chromium.googlesource.com/emscripten-releases/+/12ac1c00143f5a8a6722bdb8cca9e4515c2654d0/src/build.py#690
>
> Note that we do use out own libc++ build (which is static I believe) but we don't set LLVM_STATIC_LINK_CXX_STDLIB..  we inject it via generic cmake flags: `-DCMAKE_CXX_FLAGS=-stdlib++-isystem=.. -DCMAKE_EXE_LINKER_FLAGS=-L... -stdlib=libc++`  (this works for the other cmake projects that we also build, as well as llvm).   Perhaps we should use be passing `LLVM_STATIC_LINK_CXX_STDLIB`.

Aha. If you are specifying static build like that, it wouldn't disable clang-repl build, thus it's destined to fail. You could try setting LLVM_STATIC_LINK_CXX_STDLIB. If that is not acceptable for some reason, we could make HAVE_CLANG_REPL_SUPPORT an option so that it can be disabled manually.

> I'm curious through because things were working prior to this change.. and stopped working after this change.. even though this change is apparently targeted at fixing the exact issue that it seems to have caused for us. Rather odd.

It's actually an intended behaviour. I eliminated an existing workaround to circumvent the same failure which turned out to be not working in some out-of-tree system.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130788/new/

https://reviews.llvm.org/D130788