When statically linking C++ standard library, we shouldn't add -Bdynamic
after including the library on the link line because that might override
user settings like -static and -static-pie. Rather, we should surround
the library with --push-state/--pop-state to make sure that -Bstatic
only applies to C++ standard library and nothing else. This has been
supported since GNU ld 2.25 (2014) so backwards compatibility should
no longer be a concern.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM.
I looked at this in 2019 but did not change because GNU ld 2.25 (2014) introduced --push-state. (gold added it in 2016 but I think we can have higher version requirement for gold.)
In 2021, binutils 2.24 (2013) compatibility should be irrelevant...
clang/lib/Driver/ToolChains/Fuchsia.cpp | ||
---|---|---|
143 | --as-needed only applies to shared objects so you can move it into the else code path. | |
clang/lib/Driver/ToolChains/Gnu.cpp | ||
581 | The --as-needed change should be dropped from this patch. |
clang/test/Driver/linux-ld.c | ||
---|---|---|
499 | -no-canonical-prefixes is only useful when the CHECK lines inspect the spelling of clang. Omit -o %t.o since it is not used. | |
504 | To improve the robustness of the test, use the -SAME: {{^}} style in linux-cross.cpp, or just place these consecutive options on the same line. | |
509 | Prefer --target= to -target |
Looks like the linker used on clang-ppc64le-rhel bot doesn't support --push-state/--pop-state.
@MaskRay Do you think we should gate the use of this feature on -fbinutils-version= or -fuse-ld=lld? It'd be nice if the owner of clang-ppc64le-rhel builder could update the binutils version but I'm not sure how feasible is it.
clang/lib/Driver/ToolChains/Gnu.cpp | ||
---|---|---|
581 | --push-state should only be added when -Bstatic is added. Then the old clang-ppc64le-rhel issue may be moot because they probably don't use -static-libstdc++ ... |
clang/lib/Driver/ToolChains/Fuchsia.cpp | ||
---|---|---|
145 | as-needed needs push-state as well. |
We certainly don't mind updating binutils to a supported version. However, if a specific version of binutils (or really any other software package) is required by Clang/LLVM, that should be documented at https://llvm.org/docs/GettingStarted.html#software
Of course, if our bot has a version of binutils that is older than the one listed there currently, we will be sure to update it ASAP.
But of course, as @MaskRay pointed out, this may not be an issue.
Thanks for reaching out @nemanjai, I assume you're responsible for this builder? Do you know what version of Binutils is currently installed on that machine? Is newer version available for RHEL 7?
We don't specify Binutils version on https://llvm.org/docs/GettingStarted.html but I think we should. We need to determine that baseline first though. It looks like 2.25 roughly corresponds to GCC 5.1 which is the minimum requirement for the compiler.
This breaks our packaging builders too: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8835201798501639249/+/u/package_clang/stdout?format=raw
Note that stage 2 fails, where we're supposed to use lld. So I think this is probably some compiler-rt test config problem you need to sort out, and not a fundamental problem with the patch.
--as-needed only applies to shared objects so you can move it into the else code path.