-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
When the bootstrap code builds LLVM, it sometimes sets the CMake variable CMAKE_EXE_LINKER_FLAGS
. For example, when instructed to also build the LLVM tools:
Lines 242 to 250 in 502d6aa
if builder.config.llvm_tools_enabled { | |
if !target.contains("msvc") { | |
if target.contains("apple") { | |
cfg.define("CMAKE_EXE_LINKER_FLAGS", "-static-libstdc++"); | |
} else { | |
cfg.define("CMAKE_EXE_LINKER_FLAGS", "-Wl,-Bsymbolic -static-libstdc++"); | |
} | |
} | |
} |
When CMAKE_EXE_LINKER_FLAGS
is unset, CMake initializes it to LDFLAGS
, but it does not consider LDFLAGS
if CMAKE_EXE_LINKER_FLAGS
is set. This means that Rust's LLVM bootstrap will sometimes respect (potentially required) LDFLAGS
and sometimes not depending on a number of unexpected factors, such as whether llvm tools are also being built, whether we're building for a non-FreeBSD RISC-V target, or if we're building for powerpc-unknown-freebsd
. This, in turn, makes it difficult to bootstrap Rust in situations where additional linker flags are required, such as if dependencies are not stored in standard system-wide location such as /usr/lib
.
I propose that anywhere we set CMAKE_EXE_LINKER_FLAGS
, we append LDFLAGS
from the environment to the value to retain parity with the behavior when the configuration isn't set.