rustc: propagate libiconv on darwin

[winterqt]

Description of changes

Rust binaries are unconditionally linked to libiconv on Darwin (see rust-lang/libc#2870). We already add it as a dependency in buildRustPackage, so let's go a step further and propagate it.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • 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.

[zowoq]

@ofborg eval

[winterqt]

Why do you think retriggering eval will fix it, @zowoq? Nothing Boost-related (which is why it was failing previously) was merged into staging since the failed eval. I think it'll just fail again, unless I'm missing something.

[zowoq]

Sometimes it is an eval/build failure, sometimes it just chokes .. can usually guess by looking at other recent staging PRs.

[zowoq]

Guess we don't really have a choice here.

Are you planning to remove the unnecessary libiconv from packages after this PR is in master?

[winterqt]

Are you planning to remove the unnecessary libiconv from packages after this PR is in master?

Yes, shouldn't be too many (since most packages use buildRustPackage, I'll only have to touch packages that use the setup hooks and support Darwin, so I don't suspect a lot).

Might be better to just do it in this PR? Do you suggest not doing so only because we can get feedback from OfBorg, or...?

[zowoq]

shouldn't be too many

Quick grep looks like 100 or so?

Might be better to just do it in this PR? Do you suggest not doing so only because we can get feedback from OfBorg, or...?

Not doing it as part of this PR would mean we avoid any conflicts while it going though staging/staging-next.

[winterqt]

Not doing it as part of this PR would mean we avoid any conflicts while it going though staging/staging-next.

What do you mean by avoid? We can always just watch the staging-next eval... maybe the argument can be made that it would be more annoying, but it's not that bad.

[zowoq]

What do you mean by avoid?

Avoiding git conflicts in the master->staging-next->staging merges if someone modifies the same file(s) on master.

[winterqt]

Avoiding git conflicts in the master->staging-next->staging merges if someone modifies the same file(s) on master.

I've done treewide changes in staging before, and have never ran into any conflicts. (I have no clue how the merge action would even handle that, if at all, tbh.)

On second thought, the treewide change I'm thinking about had to be done in staging, while this doesn't have to be. So I'm comparing apples and oranges I guess.

To be clear, I was just trying to understand why doing it in master is better -- I now understand that you meant git conflicts. Happy to do it in a separate PR for that reason.

[winterqt]

FWIW any of the instances that can be removed (if any) could have been removed over a year ago. I'll look at it eventually and make a separate though; doubt it has to go through staging.

[zowoq]

FWIW any of the instances that can be removed (if any) could have been removed over a year ago.

While something like #122231 was a possibility I hadn't been to worried about doing any removals but now that it isn't going to happen may as well do a clean up.

If I have some free time I may do it myself, if I'm going to start working on it I'll leave a comment here so we aren't duplicating work.

[tjni]

Found this in the pending Rust 1.66 release notes interesting:

• Update libstd's libc to 0.2.135 (to make libstd no longer pull in libiconv.dylib on Darwin)

I don't know if this impacts what we choose to do here.

[winterqt]

It does! In fact, my issue made it happen :)

@tjni If you end up doing the 1.66 bump, I'd appreciate a poke about this then. Thanks!

[riking]

1.66 release is this week.