Bug#1010932: wasm-ld-13: unable to find library -lgcc

Faidon Liambotis paravoid at debian.org
Sun Sep 25 22:16:25 BST 2022


Control: reassign -1 libclang-common-14-dev 1:14.0.6-2
Control: retitle -1 Please build and ship compiler-rt for wasm32/wasm64
Tags: patch

Dear maintainer,

clang in Debian right now can build to the wasm32-unknown-wasi target,
as well as the less commonly used wasm64-unknown-wasi target. However,
their use is very limited, as there is no available builtins library in
Debian.

libgcc is not available for WebAssembly. compiler-rt, however, is, and
is what the WASI SDK ships with. Unfortunately it is not being shipped
in Debian right now.

In other words, this is a request to build and ship:
  /usr/lib/llvm-14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm32.a
  /usr/lib/llvm-14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm64.a

I had success in building these in a clean llvm-toolchain tree with:
  mkdir build; cd build
  cmake \
          -DCMAKE_C_COMPILER=clang \
          -DCOMPILER_RT_STANDALONE_BUILD=ON \
          -DCOMPILER_RT_BAREMETAL_BUILD=ON \
          -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=wasm32-unknown-wasi \
          -DCOMPILER_RT_OS_DIR=wasi \
          ../compiler-rt/lib/builtins/

The WASI SDK sets a few other options (BUILD_XRAY=OFF etc.) that I don't
know the use of:
  https://github.com/WebAssembly/wasi-sdk/blob/a0a342ac182caf871223797c48d00138cf67e9fb/Makefile#L102

In the package's debian/rules, this could take the form of the libclc
SPIR-V build. Specifically, something like this (untested):

  debian-rtlib-wasm32-build:
          mkdir -p compiler-rt/lib/builtins/build-wasm32
          echo "Using cmake: $(CMAKE_BIN)"
          cd compiler-rt/lib/builtins/build-wasm32 && \
          $(CMAKE_BIN) ../ \
          -G $(GENERATOR) \
          -DCMAKE_C_COMPILER=$(STAGE_2_BIN_DIR)/clang \
          -DCMAKE_CXX_COMPILER=$(STAGE_2_BIN_DIR)/clang++ \
          -DCMAKE_C_FLAGS="$(opt_flags) $(STAGE_2_CFLAGS)" \
          -DCMAKE_CXX_FLAGS="$(opt_flags) $(STAGE_2_CXXFLAGS)" \
          -DCMAKE_SHARED_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \
          -DCMAKE_MODULE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \
          -DCMAKE_EXE_LINKER_FLAGS="$(STAGE_2_LDFLAGS) -L$(STAGE_2_LIB_DIR)" \
          -DCMAKE_INSTALL_PREFIX=/usr \
          -DCMAKE_INSTALL_DATADIR=lib \
          -DCMAKE_INSTALL_INCLUDEDIR=include \
          -DLLVM_CONFIG=$(STAGE_2_BIN_DIR)/llvm-config \
          -DCOMPILER_RT_STANDALONE_BUILD=ON \
          -DCOMPILER_RT_BAREMETAL_BUILD=ON \
          -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE=wasm32-unknown-wasi \
          -DCOMPILER_RT_OS_DIR=wasi; \
          ninja $(NJOBS) $(VERBOSE)
          touch $@

(to be adjusted e.g. with a for loop for wasm64, plus hooked up on
dh_auto_build, clean etc.)

The resulting binaries could be shipped under libclang-common-14-dev,
or, given their architecture-independent nature, under a new Arch: all
package. I trust you know what's best here :)

Furthermore, given that a) there is no WASM port for libgcc b) Debian
defaults its rtlib to libgcc, this makes all out-of-the-box (i.e.
without --rtlib=compiler-rt) runs to fail. To address this, something
like this could be added to clang/lib/Driver/ToolChains/WebAssembly.cpp
to change the default to compiler-rt specifically for the WebAssembly
targets:

   ToolChain::RuntimeLibType WebAssembly::GetRuntimeLibType(
       const ArgList &Args) const {
     if (Arg* A = Args.getLastArg(options::OPT_rtlib_EQ)) {
       StringRef Value = A->getValue();
       if (Value != "compiler-rt")
         getDriver().Diag(clang::diag::err_drv_unsupported_rtlib_for_platform)
             << Value << "WebAssembly";
     }
   
     return ToolChain::RLT_CompilerRT;
   }

(This is lifted from Darwin.cpp, and is otherwise also untested.)

Hope this all helps! Apologies for not providing better patches, but
building LLVM takes many hours on machines currently available to me,
which makes iterating on this quite painful. Thank you for maintaining
LLVM in Debian -- my time spent with the package revealed its immense
complexity, and I deeply appreciate all the work it has gone into it.

Regards,
Faidon



More information about the Pkg-llvm-team mailing list