Change:
'' ## <del> ## General Clang support ## + optionalString isClang '' echo "-target ${targetPlatform.config}" >> $out/nix-support/cc-cflags '' ## </del> ## GCC libs for non-GCC support ## + optionalString useGccForLibs ''

Discussion:
I'd like to build bpf object () files but am unable to do so. Steps to reproduce the behavior: libbpf-bootstrap -shell -p clang libbpf -O2 -target bpfel -g -c -h | e:grep Machine: : , want: I expect clang to honor the I specify so that I can generate bpf object files. I was able to verify that just and are getting in the way of generating valid eBPF files. I did so by copying the wrapper script that is and seeing the final full command line that is actually invoking the real clang binary: <details<summaryUnmodified exec line (doesn't work)</summary</details<details<summaryModified exec (works)</summary</details<details<summaryruns</summary</detailsI tracked this down to cc-wrapper inserting the via which ends up living in . I'd like for it be be in instead so that I can override it. This is deep in the guts of CC support so wanted to open up an issue for discussion for this before trying to mess around with a PR. I can see why the was to the wrapper, I suspect to require use of crossSystem or similar to get a clang that will build for that arch/system but I'm not so sure thats possible for ( too?) that don't have a libc and other common tools (binutils?)... (for cc-wrapper) (for clang) Please run and paste the result.
Pretty sure a wasm target exists, it might be good to look for that. But in general would be nice to be able to override -target, yes.
would something as simple as ensuring goes into be ok?
This would allow me to remove this abomination :rocket: I can't weigh in on the possible downsides though
:nod: So far I haven't found any, no package in nixpkgs explicitly sets and would suddenly be using a target that was being silently ignored before. clang continues to work otherwise.
:toot: merged to staging, now we just have to wait for it to make it out.
Hmm I'm running into a similar problem with , in particular it contains by default. which can be trimmed down to: That's a bit difficult though, the script would have to explicitly look for target in its parameters and forbid some hardening? other default hardening options seem ok e.g.

building with works It's easy to work around by forcing the variable, but we're then losing hardening for the host part of the program which isn't what we want.
I guess that overriding the variable just for BPF calls is often difficult.
Yes, usual makefiles for this kind of bpf programs will mix a bit of everything together (I stumbled upon this with ) For a package like this I guess we could add an extra 'clang' wrapper that overrides this variable just for clang, but it's a bit of a kludge -- if we have to do this much I'd be more comfortable looking for in arguments of the current clang wrapper. I'm busy trying to debug something else, but if no other idea I'll come back to this in a few weeks with such a change to the wrapper; I was just mostly curious why this wouldn't have been the case a few months ago when this issue was current.
I always had the hardening problem with nix and bpf.
Thanks for confirming that! I've worked around the problem locally with Will open a PR with it after nixos 23.05 branched out; since it's not a new problem I believe it's better to wait than to mess with the toolchain at this point.
Oh right, such approach makes sense to me.