llvmPackages.llvm: Drop dependency on target through libbfd#355532
llvmPackages.llvm: Drop dependency on target through libbfd#355532emilazy merged 1 commit intoNixOS:stagingfrom
Conversation
github-actions
bot
added
the
6.topic: llvm/clang
|
Ideas on where to put a test for this welcome. I'm thinking it would be nice to have an assertion somewhere that checks |
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
a318410 to
5d94d6f
Compare
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
5d94d6f to
54d9479
Compare
ofborg
bot
requested review from
Ericson2314,
RossComputerGuy,
alyssais,
dtzWill,
lovek323,
rrbutani and
sternenseemann
ofborg
bot
added
10.rebuild-darwin: 1-10
|
I wonder if the header has any target specific CPP? If not, we could actually build |
emilazy
left a comment
emilazy
left a comment
There was a problem hiding this comment.
The default value of enableGoldPlugin will need adjusting (to true, presumably) to accomplish the intended result of this PR.
To achieve the final goal of a target‐independent Clang we will also have to decide what to do about the nostdlibinc patch. We could make it conditional on the target inside the patch rather than outside, but currently it just hacks into command‐line parsing where I don’t believe that information is yet reliably available, so it would likely need moving deeper into LLVM internals. Pinging @reckenrode, since AIUI he was of the opinion that the patch is working around the wrong thing.
Frankly I think we could just move that flag back to the wrapper: I believe the problem it fixes is that an unwrapped libcxxStdenv Clang picks up libstdc++ headers, but (a) it is expected that unwrapped compilers may not have all the necessary flags to integrate with Nix libraries and (b) it is normal on other distros to have to specify a flag to Clang when you want a C++ library other than the system’s default. Ideally, perhaps, we could make it so that Clang does not default to either of libstdc++ or libc++ regardless of platform, and requires a C++ library to be explicitly specified when compiling C++. I am not sure if that is a configuration knob they expose or not.
Though with that said, 1e26d33 says that there was a problem with the wrapped Clang without the patch, so I don’t know.
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
54d9479 to
fcff31e
Compare
pwaller
changed the title
|
To simplify this PR I've reduced the scope by changing the PR title and body -- now it's not quite as complete, it's just dropping the dependency on target creeping in via libbfd. Other dependency creep can be solved in other PRs. I've dropped the enableGoldPlugin and hasPluginAPI since they don't have users in nixpkgs anymore, if someone wants to disable this feature they can do so by passing |
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
fcff31e to
6c94a6f
Compare
emilazy
left a comment
emilazy
left a comment
There was a problem hiding this comment.
One required change, and this needs to target staging. LGTM otherwise.
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
6c94a6f to
0c284c8
Compare
Currently the target triple leaks into the clang build via llvm using libbfd, whose build varies according to the target triple. LLVM only uses libbfd to enable LTO via the linker plugin (called LLVMgold.so, though multiple linkers can use the same plugin). Drop the dependency on the libbfd build, and consume the only needed source instead. (This would be a good use of CA-derivations FWIW). The result of this commit is that these match: * nix eval --raw nixpkgs#clang.cc * nix eval --raw nixpkgs#pkgsStatic.pkgsLLVM.stdenv.cc.cc * nix eval --raw nixpkgs#pkgsCross.aarch64-multiplatform.pkgsLLVM.stdenv.cc.cc This means fewer clang builds will be needed to support cross configurations, and users wanting to target an exotic cross configuration should be able to do so without a rebuild of clang. Also drops libbfd.hasPluginAPI which no longer has any users. Signed-off-by: Peter Waller <[email protected]>
pwaller
force-pushed
the
drop-bfd-dependency
branch
from
0c284c8 to
7903d0b
Compare
|
Rebased to staging. |
In theory, Clang is a cross-compiler by default. After the following PRs, this is true on platforms other than Darwin. - #355532 - #356162 The reason Darwin needs additional changes is it only overlays Clang and LLVM in the native target case. When cross-compiling, it builds Clang and LLVM again. This is unnecessary as long as the Darwin stdenv avoids propagating the Clang wrappers, which are target-dependent. In theory, ld64 is also a cross-linker by default. Realizing that for nixpkgs requires additional work that will be done separately.
4 participants
Currently the target triple leaks into the clang build via llvm using
libbfd, whose build varies according to the target triple.
LLVM only uses libbfd to enable LTO via the linker plugin (called
LLVMgold.so, though multiple linkers can use the same plugin).
Drop the dependency on the libbfd build, and consume the only needed
source instead. (This would be a good use of CA-derivations FWIW).
The result of this commit is that these match:
This means fewer clang builds will be needed to support cross
configurations, and users wanting to target an exotic cross
configuration should be able to do so without a rebuild of clang.
Also drops libbfd.hasPluginAPI which no longer has any users.
Signed-off-by: Peter Waller [email protected]
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.