lib.platforms.loongarch64: init

[jackyliu16]

Description of changes

Adding the support of loongarch64 platform
but current the platform couldn't work, the detail information could be seemed in the commit messages.
Sorry, I haven't enough time to fix this problem since the middle of May, thus I have to make a kind of PR right now, and see if anyone is willing to help here.

Things done

Adding the support of loongarch64
adding a kind of mapping in linux-header from loongarch64 into loongarch
adding code in pkgs/development/tools/misc/binutils/default.nix to avoid to using gold linker in the compile of loongarch64 arch.

• 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
• Fits CONTRIBUTING.md.

[jackyliu16]

The platform seems facing a situation that it hasn't been supported by newlib and the glibc under the version 2.361, thus maybe it's need to update the version of glibc
my nixpkgs version issue, it seems the latest version of glibc is 2.37

[wegank]

pkgsCross.loongarch64-linux.hello passes, nice.

I've added the patches for building and running pkgsCross.loongarch64-linux.nix. I still think it would be better for gnugrep to upgrade to version 3.8+ (#228535), though.

@ofborg build pkgsCross.loongarch64-linux.nix

$ file result/bin/nix
result/bin/nix: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /nix/store/5i7srpc3x5yrmsaygfg1cpr4q02y758c-glibc-loongarch64-unknown-linux-gnu-2.37-8/lib/ld-linux-loongarch-lp64d.so.1, BuildID[sha1]=64b062e2172e0bcc0962dc16de8064e4274eb783, for GNU/Linux 5.19.0, not stripped

$ result/bin/nix --version
nix (Nix) 2.13.3

[alyssais]

Wouldn't it be better to merge this now, so we can fix further stuff in parallel without pushing to this single PR?

[jackyliu16]

@wegank Looks like the generated hello program could successfully run in loongarch64 machine. But Nix still failure, whatever which argument I have give.

The running linux kernel is still 4.19

[root@bogon bin]# pwd
/nix/store/zzsh8cmdcdhzx0mpznifb33bnxffhm6b-nix-loongarch64-unknown-linux-gnu-2.13.3/bin
[root@bogon zzsh8cmdcdhzx0mpznifb33bnxffhm6b-nix-loongarch64-unknown-linux-gnu-2.13.3]# ls
bin  etc  lib  libexec  share
[root@bogon zzsh8cmdcdhzx0mpznifb33bnxffhm6b-nix-loongarch64-unknown-linux-gnu-2.13.3]# cd bin/
[root@bogon bin]# ls
nix  nix-build  nix-channel  nix-collect-garbage  nix-copy-closure  nix-daemon  nix-env  nix-hash  nix-instantiate  nix-prefetch-url  nix-shell  nix-store
[root@bogon bin]# ./nix
error: querying signal mask: Invalid argument
[root@bogon bin]# file nix
nix: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /nix/store/k8l0drxnsjdrlvy2paaqrahpkq73qhnm-glibc-loongarch64-unknown-linux-gnu-2.37-8/lib/ld-linux-loongarch-lp64d.so.1, BuildID[sha1]=081ddaf4ee84797b1875b64cc39db093c6ab7518, for GNU/Linux 5.19.0, not stripped

by the ways, is it anyway to rebuild the program when the nixpkgs has changed ?

[wegank]

The running linux kernel is still 4.19

The binary compatibility with the old world is indeed not guaranteed.

By the ways, is it anyway to rebuild the program when the nixpkgs has changed?

It is not possible to avoid rebuilding the world if stdenv is affected in a non-trivial way. You will experience this from time to time if you continue to bootstrap a native loongarch64-linux stdenv.