development/libraries/glibc: work around glibc tuple-parsing bug

[ghost]

Glibc's configuration machinery cannot parse *-muslabi64, and fails with a very cryptic error message. This commit adds a --host=mips64el-linux-musl to extraConfigureFlags (so it comes after the --host= added by stdenv) in this case.

This depends on #161158 and was split off from it as requested here

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • mips64el-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.05 Release Notes (or backporting 21.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.

[ghost]

I'm a bit confused as to why ofborg says this needs 5001+ rebuilds. The added extraConfigFlags is clearly guarded by a condition that is false for all of ofborg's evaluations.

Nevermind, I figured it out, have to set extraConfigFlags to null instead of [].

This should no longer cause any rebuilds whatsoever. In light of that, I have changed the base branch to master, since this won't have any effect on any of the builds that Hydra currently performs.

[Ericson2314]

Also, I am confused why we are building glibc when we are trying to use musl!

[Ericson2314]

Will take a look.

[ghost]

Also, I am confused why we are building glibc when we are trying to use musl!

It was somewhere within

nix-build . -A pkgs.pkgsCross.mips64el-linux-gnuabi64.pkgsStatic.nix_2_4

... I'm rebuilding with this patch reverted to find the exact reason. Yeah, I recall being surprised by that too.

Note that you need to be cross-compiling a static binary. Although this sounds esoteric it is incredibly useful for producing the initial nix binary to be used on a brand-new platform. Otherwise you end up with a dynamically-linked nix that expects to find its shared libraries in /nix/store, but if you put them there manually you're doing some pretty shady stuff to what will become the target machine's store. I've done this, and it seems to sorta work, but probably isn't such a great idea.

I also think it would be nice if Hydra built static nix binaries for all the platforms it produces bootstrap-files for. I'll submit a PR for that soon.

[Ericson2314]

On the tip of master the only thing that didn't build for me was boost

 $ nix-build . -A pkgs.pkgsCross.mips64el-linux-gnuabi64.pkgsStatic.nix_2_4 --dry-run
these derivations will be built:
  /nix/store/gjayd0z6742dp30ynpcqs757kkdin7a7-boost-static-mips64el-unknown-linux-muslabi64-1.77.0.drv
  /nix/store/d7c5p1xin7x6b98pn78i0hgzakzqrd9l-nix-static-mips64el-unknown-linux-muslabi64-2.4.drv

I think that means we can close this.

[ghost]

I think that means we can close this.

Yes.

Tracking down exactly what was going on here was harder than I thought, so let me document it.

For the record: this problem was introduced in the early revisions of my PR #161158. @Ericson2314 pointed out here that I was missing cases in the "convert this platform to a statically-linked platform" function. That function had no name at the time, and was copy-pasted into multiple different places; it has since been refactored as makeStaticParsedPlatform and includes the missing cases.

pkgsStatic.nix depends on pkgsStatic.busybox. Without the missing cases mentioned above, pkgsStatic.busybox will depend on glibc-static rather than musl-libc. The end result is a mishmash of some packages linking against musl and some linking against glibc-static. Mayhem ensues.

Anyways, if this happens again, we know why.

[ghost]

the only thing that didn't build for me was boost

@Ericson2314 by the way, that is fixed by #161162, which has had no objections since it was opened almost two months ago (just two minor formatting requests, both implemented)...