Move user-defined -idirafter to the end of args

[tanshihaj]

Description of changes

As discussed in https://github.com/NixOS/nixpkgs/issues/190005 we have an issue with -idirafter arg in cc-wrapper. In this PR we add logic that moves all -idirafter to the end of arg list.

Things done

• Built on platform(s)
  • [ ] x86_64-linux
  • [ ] aarch64-linux
  • [ ] x86_64-darwin
  • [x] aarch64-darwin
• [ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• [ ] Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• [ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• [ ] Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • [ ] (Package updates) Added a release notes entry if the change is major or breaking
  • [ ] (Module updates) Added a release notes entry if the change is significant
  • [ ] (Module addition) Added a release notes entry if adding a new NixOS module
  • [ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• [ ] Fits CONTRIBUTING.md.

[tanshihaj]

@Ericson2314 Do I need some fixes here before merge?

[tanshihaj]

@veprbl Can you help me with this PR? How can I help with review?

[veprbl]

I looked at the code, and it looks fine, although it may be combined with a loop above. I have some questions regarding the intention of this.

This is supposed to allow a user to break our "soft compiler sandbox" using -idirafter, right? In the original issue you've mentioned how libSystem libc is in your way and mentioned u-boot. It makes me wonder if the stdenv of your choice is the problem. Why are you not using, say, pkgsCross.gnu64.stdenv? If using darwin stdenv is a must, you can always mangle NIX_CFLGAGS_COMPILE in your shell.nix to exclude the paths you don't lile.

[tanshihaj]

This is supposed to allow a user to break our "soft compiler sandbox" using -idirafter, right?

No, it just copy behaviour of default clang/gcc. Details here: https://github.com/NixOS/nixpkgs/issues/190005, TLDR: user-defined -idirafter should go after libc's include paths.

[veprbl]

Can the same be achieved by reversing order of concatenated items in https://github.com/NixOS/nixpkgs/blob/0446732359536566de33d8893bd4c682174e31e2/pkgs/build-support/cc-wrapper/add-flags.sh#L51 ?

[tanshihaj]

No, unfortunately not. We need to move all -idirafter flags from params to end of extraAfter. Changing order in NIX_CFLAGS_COMPILE_@suffixSalt@ will just move them inside extraAfter environment variable.

But I just realized that maybe it would be good idea to move -idirafter with libc include paths to separate variable and put it to extraBefore, that will make while (( $n < $N )); do unnecessary and source code will look better.

[tanshihaj]

I've tried to implement solution I described above and now I cannot compile glibc. We cannot just pull libc-cflags (which contains -idirafter with libc include dirs) and put it into extraBefore: crt1-cflags, libc-cflags, cc-cflags must remain in specific order: https://github.com/NixOS/nixpkgs/blob/0446732359536566de33d8893bd4c682174e31e2/pkgs/build-support/cc-wrapper/add-flags.sh#L36-L41

So the only solution is to collect all user-defined -idirafter and put them into end of extraAfter, which is already implemented in PR.

[tanshihaj]

Yes, I agree that solution in pr is a bit ugly, will try to find another way to do it.

[tanshihaj]

Ok, I give up - unfortunately I do not have enough knowledge (or time to get this knowledge) to fix both https://github.com/NixOS/nixpkgs/issues/190005 and https://github.com/NixOS/nixpkgs/issues/158042 in one solution. Closing PR.