Skip to content

[CMake][Release] Statically link clang with stage1 runtimes #127268

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Feb 20, 2025

Conversation

tstellar
Copy link
Collaborator

This change will cause clang and the other tools to statically link against the runtimes built in stage1. This will make the built binaries more portable by eliminating dependencies on system libraries like libgcc and libstdc++.

This change will cause clang and the other tools to statically link
against the runtimes built in stage1.  This will make the built binaries
more portable by eliminating dependencies on system libraries like
libgcc and libstdc++.
@tstellar tstellar requested a review from tru February 14, 2025 21:59
@llvmbot llvmbot added the clang Clang issues not falling into any other category label Feb 14, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 14, 2025

@llvm/pr-subscribers-flang-runtime

@llvm/pr-subscribers-clang

Author: Tom Stellard (tstellar)

Changes

This change will cause clang and the other tools to statically link against the runtimes built in stage1. This will make the built binaries more portable by eliminating dependencies on system libraries like libgcc and libstdc++.


Full diff: https://github.com/llvm/llvm-project/pull/127268.diff

1 Files Affected:

  • (modified) clang/cmake/caches/Release.cmake (+16-4)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 23e99493087ff..290e186baf6fe 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -48,10 +48,8 @@ set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
 
 set(STAGE1_PROJECTS "clang")
 
-# Building Flang on Windows requires compiler-rt, so we need to build it in
-# stage1.  compiler-rt is also required for building the Flang tests on
-# macOS.
-set(STAGE1_RUNTIMES "compiler-rt")
+# Build all runtimes so we can statically link them into the stage2 compiler.
+set(STAGE1_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind")
 
 if (LLVM_RELEASE_ENABLE_PGO)
   list(APPEND STAGE1_PROJECTS "lld")
@@ -90,9 +88,18 @@ else()
   set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING "")
 endif()
 
+if (LLVM_RELEASE_ENABLE_LTO)
+  # Enable LTO for the runtimes.  We need to configure stage1 clang to default
+  # to using lld as the linker because the stage1 toolchain will be used to
+  # build and link the runtimes.
+  set(RUNTIMES_CMAKE_ARGS "-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON" CACHE STRING "")
+  set(LLVM_ENABLE_LLD ON CACHE STRING "")
+endif()
+
 # Stage 1 Common Config
 set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
 set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
+set(LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY ON CACHE STRING "")
 
 # stage2-instrumented and Final Stage Config:
 # Options that need to be set in both the instrumented stage (if we are doing
@@ -102,6 +109,11 @@ set_instrument_and_final_stage_var(LLVM_ENABLE_LTO "${LLVM_RELEASE_ENABLE_LTO}"
 if (LLVM_RELEASE_ENABLE_LTO)
   set_instrument_and_final_stage_var(LLVM_ENABLE_LLD "ON" BOOL)
 endif()
+set_instrument_and_final_stage_var(LLVM_ENABLE_LIBCXX "ON" BOOL)
+set_instrument_and_final_stage_var(LLVM_STATIC_LINK_CXX_STDLIB "ON" BOOL)
+set_instrument_and_final_stage_var(CMAKE_EXE_LINKER_FLAGS "-rtlib=compiler-rt --unwindlib=libunwind -static-libgcc" STRING)
+set_instrument_and_final_stage_var(CMAKE_SHARED_LINKER_FLAGS "-rtlib=compiler-rt --unwindlib=libunwind -static-libgcc" STRING)
+set_instrument_and_final_stage_var(CMAKE_MODULE_LINKER_FLAGS "-rtlib=compiler-rt --unwindlib=libunwind -static-libgcc" STRING)
 
 # Final Stage Config (stage2)
 set_final_stage_var(LLVM_ENABLE_RUNTIMES "${LLVM_RELEASE_ENABLE_RUNTIMES}" STRING)

I think this first stopped working with
9548366.  This patch fixes the
following error:

/home/runner/work/llvm-project/llvm-project/flang/runtime/io-api-minimal.cpp:153:11: error: '__libcpp_verbose_abort' is missing exception specification 'noexcept'
   153 | void std::__libcpp_verbose_abort(char const *format, ...) {
       |           ^
       |                                                           noexcept
/mnt/build/bin/../include/c++/v1/__verbose_abort:30:28: note: previous declaration is here
    30 |     __printf__, 1, 2) void __libcpp_verbose_abort(const char* __format, ...) _LIBCPP_VERBOSE_ABORT_NOEXCEPT;
       |                            ^
1 error generated.
@llvmbot llvmbot added flang:runtime flang Flang issues not falling into any other category labels Feb 15, 2025
Copy link

github-actions bot commented Feb 15, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Collaborator

@tru tru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one question.

# Enable LTO for the runtimes. We need to configure stage1 clang to default
# to using lld as the linker because the stage1 toolchain will be used to
# build and link the runtimes.
set(RUNTIMES_CMAKE_ARGS "-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON -DLLVM_ENABLE_LLD=ON" CACHE STRING "")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't use LLVM_ENABLE_LTO=Thin here? It would be more explicit that we enable ThinLTO over whatever CMake deems good in that case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLVM_ENABLE_LTO=Thin causes some of the CMake checks for the runtime build to fail which fails the whole build. -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON does enable ThinLTO, so it's effectively the same.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's odd. Maybe we could at least say why we are not using that flag there since that's the one that's documented in the llvm documentation.

@tstellar tstellar merged commit f5b311e into llvm:main Feb 20, 2025
8 of 14 checks passed
@tstellar tstellar added this to the LLVM 20.X Release milestone Feb 20, 2025
@tstellar
Copy link
Collaborator Author

/cherry-pick f5b311e

@llvmbot
Copy link
Member

llvmbot commented Feb 20, 2025

/pull-request #127949

swift-ci pushed a commit to swiftlang/llvm-project that referenced this pull request Feb 21, 2025
)

This change will cause clang and the other tools to statically link
against the runtimes built in stage1. This will make the built binaries
more portable by eliminating dependencies on system libraries like
libgcc and libstdc++.

(cherry picked from commit f5b311e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang Clang issues not falling into any other category flang:runtime flang Flang issues not falling into any other category
Projects
Development

Successfully merging this pull request may close these issues.

3 participants