[CI] Static-link libstdc++ for Linux wheel builds#19804
Conversation
The Linux manylinux_2_28 wheels fail their cibuildwheel test step with "undefined symbol: ...basic_string..._M_replace_cold@GLIBCXX_3.4.30" when importing tvm. The C++20 baseline requires a newer gcc-toolset (GCC 14 in the current manylinux image), whose libstdc++ emits symbols newer than the manylinux runtime baseline. Because auditwheel does not bundle libstdc++, the wheel ends up with a runtime dependency on a libstdc++ that the test/host environment does not provide. Add LDFLAGS="-static-libstdc++ -static-libgcc" to the Linux wheel build environment so the C++ runtime is linked statically into libtvm.so / libtvm_runtime.so, removing the dynamic libstdc++ dependency. macOS (libc++) and Windows (MSVC STL) are unaffected.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Linux wheel build action to statically link libstdc++ and libgcc, preventing runtime loading issues on older host environments. The reviewer noted that the CUDA runtime sidecar, libtvm_runtime_cuda.so, is built separately and will still dynamically link against the newer libstdc++. They recommended also statically linking libstdc++ and libgcc in the separate CUDA runtime build script.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| CIBW_ENVIRONMENT_LINUX: >- | ||
| CMAKE_PREFIX_PATH="/opt/llvm" | ||
| LIBRARY_PATH="/opt/llvm/lib" | ||
| LDFLAGS="-static-libstdc++ -static-libgcc" |
There was a problem hiding this comment.
While adding LDFLAGS="-static-libstdc++ -static-libgcc" here statically links the C++ runtime for libtvm.so and libtvm_runtime.so built during the main wheel build, the CUDA runtime sidecar libtvm_runtime_cuda.so (specified in TVM_PACKAGE_EXTRA_LIBS) is built separately via ci/scripts/package/manylinux_build_libtvm_runtime_cuda.sh. If libtvm_runtime_cuda.so is built in a container with a newer GCC/toolset, it will still dynamically link against the newer libstdc++ and fail to load on older host environments with the same undefined symbol error. To address this, also statically link libstdc++ and libgcc when building libtvm_runtime_cuda.so by passing -DCMAKE_SHARED_LINKER_FLAGS="-static-libstdc++ -static-libgcc" to the cmake command in ci/scripts/package/manylinux_build_libtvm_runtime_cuda.sh.
|
Decided to revert the c++20 baseline switch for now (#19805). Closing this PR. |
1 participant
The Linux manylinux_2_28 wheels fail their cibuildwheel test step with "undefined symbol: ...basic_string..._M_replace_cold@GLIBCXX_3.4.30" when importing tvm. The C++20 baseline requires a newer gcc-toolset (GCC 14 in the current manylinux image), whose libstdc++ emits symbols newer than the manylinux runtime baseline. Because auditwheel does not bundle libstdc++, the wheel ends up with a runtime dependency on a libstdc++ that the test/host environment does not provide.
Add LDFLAGS="-static-libstdc++ -static-libgcc" to the Linux wheel build environment so the C++ runtime is linked statically into libtvm.so / libtvm_runtime.so, removing the dynamic libstdc++ dependency. macOS (libc++) and Windows (MSVC STL) are unaffected.