release-notes: add autoPatchelfHookWithLibgcc, explain libgcc changes

[ghost]

Description of changes

This PR contains two commits:

1. Add autoPatchelfHookWithLibgcc, which is the "dammit just make it work" copypasta for people who get stung by the libgcc changes.
2. Add (quite a bit of) text to the release notes to try to help out-of-tree Nix packages which are downstream of nixpkgs and encounter breakage due to the libgcc changes.

Closes #225963

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

[ghost]

Note: I will be offline from sometime in the next few hours until after the end of the month.

Please don't hesitate to edit this PR aggressively if necessary. I'm unlikely to be able to respond to review comments before the release deadline.

[ncfavier]

Pushed a fix to the NixOS manual.

By the way, why or null?

[ghost]

By the way, why or null?

Because stdenv.cc might not have a libgcc output. Two cases come to mind:

1. Future: using a non-gcc compiler (clang?)
2. Current: even our gcc does not always create a libgcc output. Here are the current conditions which cause its creation, but these may (and almost certainly will) change in the future.

[ghost]

Note: I will be offline from sometime in the next few hours until after the end of the month.

Please don't hesitate to edit this PR aggressively if necessary. I'm unlikely to be able to respond to review comments before the release deadline.

I'm back and pretty close to conquering my backlog. Not sure if this is still being considered for the release (would technically be a "backport" at this point), but I can respond to comments now.

[ncfavier]

Because stdenv.cc might not have a libgcc output.

Shouldn't compilation of things that depend on libgcc fail in those cases? (or is libgcc included by other means?)

[ghost]

There are many situations where stdenv.cc doesn't have a libgcc output:

• pkgsStatic
• cross-compilers to platforms which lack dynamic linkers (arm-none-eabi)
• a hypothetical future non-gcc-based stdenv

Shouldn't compilation of things that depend on libgcc fail in those cases?

Unfortunately no. This is the big problem with libgcc. The glibc developers have decided to dlopen() it and not build with -lgcc, so the dependency is completely invisible to nixpkgs and patchelf. This is the root cause of all our troubles. Note that this is very similar to the headaches which led to /run/opengl-driver as well as NixOS's reliance on nscd. dlopen() simply doesn't align well with Nix's worldview.