bupstash, httm, rustpython: unbreak on x86_64-darwin

[wegank]

Description of changes

Maybe the approach in #180931 is more appropriate, but well, at least this fixes the builds...

@prusnak Would you like to take a look?

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/)
• 23.05 Release Notes (or backporting 22.11 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.

[prusnak]

Tested ACK (builds and runs on both x86_64-darwin and aarch64-darwin).

I think the selected approach is the best way how to fix Rust stuff on x86_64-darwin.

[risicle]

Build of rustpython fails for me on macos 10.15 with:

... "/private/tmp/nix-build-rustpython-unstable-2022-10-11.drv-0/rustcLFkw5h/liblibz_sys-20dafea5d1a0a1f5.rlib" "/nix/store/jm0hjqf69frydhbsicw2is6bkkqqvqqb-rustc-1.65.0/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-3097cb3d32beb6d3.rlib" "-lc" "-framework" "SystemConfiguration" "-framework" "CoreFoundation" "-liconv" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" "-L" "/nix/store/jm0hjqf69frydhbsicw2is6bkkqqvqqb-rustc-1.65.0/lib/rustlib/x86_64-apple-darwin/lib" "-o" "/private/tmp/nix-build-rustpython-unstable-2022-10-11.drv-0/source/target/x86_64-apple-darwin/release/deps/rustpython-b0f2d5c278c4a86b" "-Wl,-dead_strip" "-nodefaultlibs"
    = note: /nix/store/3mdvw7gabrzixwa5capbvxbngz4dv70r-clang-wrapper-11.1.0/bin/ld: line 254: /nix/store/b89dcicsmqr71fm61nqzfg2afydr0w97-cctools-binutils-darwin-973.0.1/bin/ld: Argument list too long

following an extremely long ld command

[wegank]

I guess the length falls between #define ARG_MAX (256 * 1024) on macOS 10.15 and #define ARG_MAX (1024 * 1024) on macOS 11+, and it seems like ARG_MAX can't be changed. What a pity.

And also, linking to the meta issue at #41340.

[prusnak]

@risicle Can you figure out how long is the command line? I am wondering whether we are tripping on ARG_MAX or stack size (ulimit -s).

Not sure how is it on Darwin but SO says that "On Linux, the maximum amount of space for command arguments is 1/4th of the amount of available stack space. So, a solution is to increase the amount of space available for the stack." - from https://unix.stackexchange.com/a/45584

[prusnak]

Was this closed because it's not needed anymore or another reason?

[wegank]

I relaunched the PR in #214119 in a slightly different way, as I haven't got as many reviews to be sure to merge it.