-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: treewide: Always prefix compilers #44583
Conversation
Then we don't run the risk of stomping over non-autotools.
This isn't needed now that we use env vars.
GNU tools are prefixed the same whether wrapped or not, but unwrapped LLVM tools are not prefixed because they are multi-target.
It's confusing when the linker and assembler appear to come from cc-wrapper rather than bintools-wrapper.
The unwrapped bintools are already propagated dependencies, and therefore on the PATH of downstream builds, cc-wrapper can get the assembler on its own.
This isn't a MUSL thing, but just needed for cross compilation to x86. No one had tried this when all cross compilation was to linux + glibc, hence why no one noticed this until recently.
Carefully fake cc-version and cc-fullversion to avoid needing a compiler for the kernel itself to build the headers.
99d349f
to
6c60a14
Compare
I only glanced very quickly over the changes and this wasn't immediately clear, the un-prefixed wrappers are still available and work right? |
sed "s|--owner 0 --group 0||g" -i Makefile | ||
sed -i Makefile \ | ||
-e 's|--owner 0 --group 0||g' \ | ||
-e '/CC:=gcc/d' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any use for paxctl/grsecurity at all? We removed the kernel long time ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I don't. But it's part of bootstrapping; that's why I fixed it.
@LnL7 actually wrapped binaries are always prefixed with this PR. But I could make |
NAK for removing unprefixed |
|
||
# Skip clean on darwin, case-sensitivity issues. | ||
buildPhase = lib.optionalString (!buildPlatform.isDarwin) '' | ||
make mrproper $makeFlags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use buildFlags & checkFlags here instead?
Can we have an unprefixed symlink for the host compiler? Even just something like:
Would cover most use cases. Maybe one for gcc as well because that's often hardcoded. |
I completely agree with the gain offered by always prefixing the compilers in stdenv: it is the removal of another source of impurity (the host system), which is what nix is all about. However, a cursory read (which can easily be wrong) makes me think |
I sort of rather fix that after as |
Are there any updates on this pull request, please? |
It looks like there hasn't been any updates on this in a year, so I will close it. (@Ericson2314 sorry in advance if you're still working on any of these PRs that I've closed. Definitely don't hesitate to re-open. I've been trying to clean up old PRs tagged |
@cdepillabout It's fine. I'll reopen if/when I get back to them. |
Motivation for this change
The goal is to bring the native and cross code paths closer together by always prefixing compilers. This makes it easier to catch programs that hard-code
gcc
orclang
.This also includes:
gcc
fix is needed.CC
,LD
, and friends use full paths instead of names, generally good for robustness.The whole thing I plan to merge after 18.09, but maybe those 2 bits can go in first.
Fixes #21471
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)