gcc: create dummy crtstuff on loongarch64

[wegank]

Description of changes

A hacky workaround to fix #252590.

The workaround can be trivially modified to work for #243614, but the underlying reason is unjustified. I've therefore decided not to generalize this PR.

Things done

• Built on platform(s)
  • loongarch-linux (cross)
  • 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.11 Release Notes (or backporting 23.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
• Fits CONTRIBUTING.md.

[wegank]

@ofborg build pkgsCross.loongarch64-linux.freshBootstrapTools.bootstrapFiles

[wegank]

@trofi, would you like to have a look?

[trofi]

@trofi, would you like to have a look?

I'm afraid I can't comment on the fix's usefullness. If it works for you then yay!

nixpkgs degraded quite a bit in ability to cross-commpile even simple linux-targeting toolchains after #238154 and #241206 and regressions after an obvious (to me) breakage are still not fixed.

After those it's very hard to reason about pre-libc gcc in nixpkgs. It differs from what upstream expects and what other distributions expect from the bootstrap.

Maybe reviewers of the changes above or gcc maintainers can help you to review it.

If it helps I can re-iterate what an usual expectation is for gcc cross-build:

1. cross-binutils is built (no c++ or c sipport on target)
2. cross-gcc is built (no libc or shared library support on target, libgcc.aprovides onlygcc` primitives and does not implement external unwinder)
3. target glibc is built (no c++ support on target)
4. cross-gcc is built with full support for shared libraries (we have glibc crt to do it)
5. target glibc is built (c++ and unwinder support for target)

I can reason about [4.] state of gcc built. But nixpkgs (AFAIU) does something very different and confuses gcc around detection of various target features like global constructor support.

It would be nice to compare config.log you get from your fix and the hypothetical [2.] and [.4] builds. Maybe they are close enough.