-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[CMake][Release] Stop linking against stage1 runtimes #164017
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
base: main
Are you sure you want to change the base?
Conversation
This was causing a build failure on Darwin and a test failure on Linux. This config is not widely used or well tested, so I don't think the potential and likely small performance gains and the portability from this are worth the maintenance costs.
@llvm/pr-subscribers-clang Author: Tom Stellard (tstellar) ChangesThis was causing a build failure on Darwin and a test failure on Linux. This config is not widely used or well tested, so I don't think the potential and likely small performance gains and the portability from this are worth the maintenance costs. Full diff: https://github.com/llvm/llvm-project/pull/164017.diff 1 Files Affected:
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index a523cc561b3f9..9aa7178537397 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -44,6 +44,19 @@ set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PGO ON CACHE BOOL "")
set(LLVM_RELEASE_ENABLE_RUNTIMES ${DEFAULT_RUNTIMES} CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PROJECTS ${DEFAULT_PROJECTS} CACHE STRING "")
+
+# This option enables linking stage2 clang statically with the runtimes
+# (libc++ and compiler-rt) from stage1. In theory this will give the
+# binaries better performance and make them more portable. However,
+# this configuration is not well tested and causes build failures with
+# the flang-rt tests cases, since the -stclib=libc++ flag does not
+# get propagated to the runtimes build. There is also a separate
+# issue on Darwin where clang will use the local libc++ headers, but
+# link with system libc++ which can cause some incompatibilities.
+# See https://github.com/llvm/llvm-project/issues/77653
+# Because of these problems, this option will default to OFF.
+set(LLVM_RELEASE_LINK_LOCAL_RUNTIMES OFF CACHE BOOL "")
+
# Note we don't need to add install here, since it is one of the pre-defined
# steps.
set(LLVM_RELEASE_FINAL_STAGE_TARGETS "clang;package;check-all;check-llvm;check-clang" CACHE STRING "")
@@ -55,8 +68,12 @@ set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
set(STAGE1_PROJECTS "clang")
+# Need to build compiler-rt in order to use PGO for later stages.
+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_LINK_LOCAL_RUNTIMES)
+ list(APPEND STAGE1_RUNTIMES "libcxx;libcxxabi;libunwind")
+endif()
if (LLVM_RELEASE_ENABLE_PGO)
list(APPEND STAGE1_PROJECTS "lld")
@@ -118,11 +135,13 @@ 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(RELEASE_LINKER_FLAGS "-rtlib=compiler-rt --unwindlib=libunwind")
-if(NOT ${CMAKE_HOST_SYSTEM_NAME} MATCHES "Darwin")
- set(RELEASE_LINKER_FLAGS "${RELEASE_LINKER_FLAGS} -static-libgcc")
+if(LLVM_RELEASE_LINK_LOCAL_RUNTIMES)
+ 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(RELEASE_LINKER_FLAGS "-rtlib=compiler-rt --unwindlib=libunwind")
+ if(NOT ${CMAKE_HOST_SYSTEM_NAME} MATCHES "Darwin")
+ set(RELEASE_LINKER_FLAGS "${RELEASE_LINKER_FLAGS} -static-libgcc")
+ endif()
endif()
# Set flags for bolt
@@ -130,9 +149,11 @@ if (${CMAKE_HOST_SYSTEM_NAME} MATCHES "Linux")
set(RELEASE_LINKER_FLAGS "${RELEASE_LINKER_FLAGS} -Wl,--emit-relocs,-znow")
endif()
-set_instrument_and_final_stage_var(CMAKE_EXE_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
-set_instrument_and_final_stage_var(CMAKE_SHARED_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
-set_instrument_and_final_stage_var(CMAKE_MODULE_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
+if (RELEASE_LINKER_FLAGS)
+ set_instrument_and_final_stage_var(CMAKE_EXE_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
+ set_instrument_and_final_stage_var(CMAKE_SHARED_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
+ set_instrument_and_final_stage_var(CMAKE_MODULE_LINKER_FLAGS ${RELEASE_LINKER_FLAGS} STRING)
+endif()
# Final Stage Config (stage2)
set_final_stage_var(LLVM_ENABLE_RUNTIMES "${LLVM_RELEASE_ENABLE_RUNTIMES}" STRING)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couple of minor comments, but otherwise LGTM cheers
# link with system libc++ which can cause some incompatibilities. | ||
# See https://github.com/llvm/llvm-project/issues/77653 | ||
# Because of these problems, this option will default to OFF. | ||
set(LLVM_RELEASE_LINK_LOCAL_RUNTIMES OFF CACHE BOOL "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
set(LLVM_RELEASE_LINK_LOCAL_RUNTIMES OFF CACHE BOOL "") | |
set(LLVM_RELEASE_ENABLE_LINK_LOCAL_RUNTIMES OFF CACHE BOOL "") |
set(LLVM_RELEASE_ENABLE_PROJECTS ${DEFAULT_PROJECTS} CACHE STRING "") | ||
|
||
# This option enables linking stage2 clang statically with the runtimes | ||
# (libc++ and compiler-rt) from stage1. In theory this will give the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like compiler-rt is linked against regardless of this flag, so perhaps worth dropping from the list here?
This was causing a build failure on Darwin and a test failure on Linux. This config is not widely used or well tested, so I don't think the potential and likely small performance gains and the portability from this are worth the maintenance costs.