nixos/ldso: avoid instance of nixpkgs

[zimbatm]

Follow up to #269551

Avoid creating a new instance of nixpkgs to access two variables.
pkgs.pkgsi686Linux was being accessed whenever the feature is being
used or not.

A second instance of nixpkgs is being created in
nixos/modules/config/stub-ld.nix and can be disabled by setting
environment.ldso32 = null or environment.stub-ld.enable = false.

Both combined fixes this error:

error: attribute 'i686-linux' missing

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[zimbatm]

@yu-re-ka mind trying this out?

[infinisil]

Both combined fixes this error:

error: attribute 'i686-linux' missing

How to reproduce?

[yu-re-ka]

Not the same error, but my issue can be reproduced by setting

nixpkgs.hostPlatform.config = "x86_64-unknown-linux-musl";

The exact error is described here: #269551 (comment)

[zimbatm]

I wasn't able to create a repro, both our use cases are related to creating these new instances of nixpkgs.

[yu-re-ka]

I still think it would be nicer to test for the evaluation of the stdenv of pkgsi686Linux somehow and check that it is supported (and then do that check instead of the isx86_64).

But for now this would give me a workaround other than cutting out the ldso module entirely.

[zimbatm]

Ran a quick benchmark on one of my desktop configs. The patch doesn't make a lot of difference, but disabling environment.stub-ld.enable saves a whopping 80MiB of evaluation. A 4% difference on my fairly complete desktop config.

[yu-re-ka]

@zimbatm does it still make such a difference when other 32-bit libs are already being evaluated like hardware.pulseaudio.support32Bit or hardware.opengl.driSupport32Bit ?

[Atemu]

What I don't yet understand is why it would eval pkgsi686Linux when lsdo = null. Shouldn't it should remain a thunk in that case?

Another thing we might look into is to see whether these variables we need are available through other means. Since this is x86_64-only, we could take libDir from lib.systems.elaborate "i686-linux" for instance.

I don't like defining such values in multiple places. OTOH, this value is pretty much constant.

[tejing1]

What I don't yet understand is why it would eval pkgsi686Linux when lsdo = null. Shouldn't it should remain a thunk in that case?

Because it still needs to generate a rule deleting the previously existing link, and the file path of that rule is determined from pkgsi686Linux

Another thing we might look into is to see whether these variables we need are available through other means. Since this is x86_64-only, we could take libDir from lib.systems.elaborate "i686-linux" for instance.

I like this idea better. Perhaps we can add the other needed information to the system elaboration as well?

I don't like defining such values in multiple places. OTOH, this value is pretty much constant.

I also don't like hardcoding it here, in the long term. But it's a reasonable stopgap measure, in my view.

[Atemu]

Perhaps we can add the other needed information to the system elaboration as well?

Could we? Some of that might be linked (heh) to the libc you're using.

[tejing1]

The more I think about it, the more I think this is actually fine. The entire way multiarch stuff on x86 is handled is pretty ad-hoc anyway, without a proper abstraction within nixpkgs and/or nixos. Trying to grab the info from elsewhere really might not add much of anything in terms of cleanliness/robustness, until such a general multiarch abstraction exists, at which point all this will need reworking anyway.

Good to leave a comment about where the hardcoded information came from, and why it's hardcoded, though.

[tejing1]

With minor tweaks, looks good to me.

[zimbatm]

Ok, I'm glad we managed to find some compromise. Given that it's legacy support, I don't expect those constants to change.

Probably a better name for environment.ldso32 would be environment.ldso_legacy or environment.x86_64_fallback given how environment-specific it is. But all of this is a bit of a puzzle.

does it still make such a difference when other 32-bit libs are already being evaluated like...

It still saves 1.4% of GC in my non-scientific test. I'm also thinking of server scenarios where those options would not be enabled.