[libcxx] [docs] Update the MinGW build example #68790
Conversation
The previous example wasn't a configuration that we actually test, but was a simplistic configuration with libstdc++ as ABI library. The previous example configuration has bitrotted and broken in a couple different ways since it was added: - In b0fd949, libcxx added uses of weak symbols that can be overridden by the user. GNU ld fails to export such weak symbols on MinGW, resulting in errors like: C:/msys64/mingw64/bin/ld: cannot export _ZNSt3__126__libcpp_assertion_handlerEPKciS1_S1_: symbol wrong type (2 vs 3) By switching to using LLD, -DLLVM_ENABLE_LLD=ON, alternatively -DCMAKE_SHARED_LINKER_FLAGS=-fuse-ld=lld, linking still succeeds. - In a80e65e, building with -DLIBCXX_CXX_ABI=libstdc++ in this configuration started failing. Switch to showing how to build with libcxxabi instead, which is the tested configuration and also is the typical configuration in how it most usually would be used on Windows.
mstorsjo
added
libc++
|
@llvm/pr-subscribers-libcxx @llvm/pr-subscribers-libcxxabi Author: Martin Storsjö (mstorsjo) ChangesThe previous example wasn't a configuration that we actually test, but was a simplistic configuration with libstdc++ as ABI library. The previous example configuration has bitrotted and broken in a couple different ways since it was added:
These updates allow removing the mentions of the old caveats with the build configuration. Full diff: https://github.com/llvm/llvm-project/pull/68790.diff 1 Files Affected:
diff --git a/libcxx/docs/BuildingLibcxx.rst b/libcxx/docs/BuildingLibcxx.rst
index e919e1e6f32bfc3..e33d2dce288d098 100644
--- a/libcxx/docs/BuildingLibcxx.rst
+++ b/libcxx/docs/BuildingLibcxx.rst
@@ -160,19 +160,13 @@ e.g. the ``mingw-w64-x86_64-clang`` package), together with CMake and ninja.
> cmake -G Ninja -S runtimes -B build \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
- -DLLVM_ENABLE_RUNTIMES=libcxx \
- -DLIBCXX_CXX_ABI=libstdc++
+ -DLLVM_ENABLE_LLD=ON \
+ -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" \
+ -DLIBCXXABI_ENABLE_SHARED=OFF \
+ -DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON
> ninja -C build cxx
- > cp /mingw64/bin/{libstdc++-6,libgcc_s_seh-1,libwinpthread-1}.dll lib
> ninja -C build check-cxx
-As this build configuration ends up depending on a couple other DLLs that
-aren't available in path while running tests, copy them into the same
-directory as the tested libc++ DLL.
-
-(Building a libc++ that depends on libstdc++ isn't necessarily a config one
-would want to deploy, but it simplifies the config for testing purposes.)
-
.. _`libc++abi`: http://libcxxabi.llvm.org/
|
The previous example wasn't a configuration that we actually test, but was a simplistic configuration with libstdc++ as ABI library.
The previous example configuration has bitrotted and broken in a couple different ways since it was added:
In b0fd949, libcxx added uses of weak symbols that can be overridden by the user. GNU ld fails to export such weak symbols on MinGW, resulting in errors like: C:/msys64/mingw64/bin/ld: cannot export ZNSt3__126__libcpp_assertion_handlerEPKciS1_S1: symbol wrong type (2 vs 3) By switching to using LLD, -DLLVM_ENABLE_LLD=ON, alternatively -DCMAKE_SHARED_LINKER_FLAGS=-fuse-ld=lld, linking still succeeds.
In a80e65e, building with -DLIBCXX_CXX_ABI=libstdc++ in this configuration started failing. Switch to showing how to build with libcxxabi instead, which is the tested configuration and also is the typical configuration in how it most usually would be used on Windows.
These updates allow removing the mentions of the old caveats with the build configuration.