Skip to content

bootstrap: LLVM build disregards LDFLAGS #93880

Closed

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions