In reply to @trofi:matrix.org
Looks like it's intentional after all: It's added by ...-glibc-2.35-224/lib/libc.so: GROUP ( ...-glibc-2.35-224/lib/libc.so.6 ...-glibc-2.35-224/lib/libc_ nonshared.a AS_NEEDED ( ...-glibc-2.35-224/lib/ld-linux-aarch64.so.1 ) ) and provides __stack_chk_guard@@GLIBC_2.17 symbol.

In reply to @trofi:matrix.org
Looks like it's intentional after all: It's added by ...-glibc-2.35-224/lib/libc.so: GROUP ( ...-glibc-2.35-224/lib/libc.so.6 ...-glibc-2.35-224/lib/libc_ nonshared.a AS_NEEDED ( ...-glibc-2.35-224/lib/ld-linux-aarch64.so.1 ) ) and provides __stack_chk_guard@@GLIBC_2.17 symbol.

In reply to @winterqt:nixos.dev
Where did you find this info?

In reply to @winterqt:nixos.dev
Where did you find this info?

Ran

$ nix develop -f. hello --argstr system aarch64-linux
$ unpackPhase; cd hello*; patchPase; configurePhase; buildPhase

Then explore unstripped/unpatchelf-ed hello and realized it has the dependency.
Then explored gcc -o hello ... command, added -v to it and extracted ld call. That still produced a reference.
Then added -shared flag to allow removing almost all .o files and noticed that at some point ld.so NEEDED dependency disappears. That means it was an explicit linkage input and some symbol is retaining it.
Then ran nm -D on ld.so and on hello to see if there are suspects that are exported from ld.so and are imported to hello. __stack_chk_guard looked obvious.
Then checked all the inputs if they are linker scripts. libc.so ended up one.

In reply to @winterqt:nixos.dev
Where did you find this info?

Ran

$ nix develop -f. hello --argstr system aarch64-linux
$ unpackPhase; cd hello*; patchPase; configurePhase; buildPhase

Then explored unstripped/unpatchelf-ed hello and realized it has the dependency.
Then explored gcc -o hello ... command, added -v to it and extracted ld call. That still produced a reference.
Then added -shared flag to allow removing almost all .o files and noticed that at some point ld.so NEEDED dependency disappears. That means it was an explicit linkage input and some symbol is retaining it.
Then ran nm -D on ld.so and on hello to see if there are suspects that are exported from ld.so and are imported to hello. __stack_chk_guard looked obvious.
Then checked all the inputs if they are linker scripts. libc.so ended up one.

In reply to @winterqt:nixos.dev
Where did you find this info?

❯ nix build -f . curl.tests
error:
       … while calling a functor (an attribute set with a '__functor' attribute)

         at /home/hexa/git/nixos/staging/pkgs/tools/networking/curl/default.nix:171:20:

          170|       withCheck = finalAttrs.finalPackage.overrideAttrs (_: { doCheck = true; });
          171|       fetchpatch = tests.fetchpatch.simple.override { fetchpatch = fetchpatch.override { fetchurl = useThisCurl fetchurl; }; };
             |                    ^
          172|       curlpp = useThisCurl curlpp;

       … while evaluating a branch condition

         at /home/hexa/git/nixos/staging/lib/customisation.nix:92:7:

           91|     in
           92|       if builtins.isAttrs result then
             |       ^
           93|         result // {

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: attribute 'version' missing

       at /home/hexa/git/nixos/staging/pkgs/build-support/fetchpatch/tests.nix:4:19:

            3| let
            4|   isFetchpatch2 = fetchpatch.version == 2;
             |                   ^
            5| in

not sure if the fetchers are stdenv material, but looks like fetchpatch2 changes have broken curls passthru tests 🙂 cc Artturin

  fetchpatch = callPackage ../build-support/fetchpatch {
    # 0.3.4 would change hashes: https://github.com/NixOS/nixpkgs/issues/25154
    patchutils = buildPackages.patchutils_0_3_3;
  } // {
    tests = pkgs.tests.fetchpatch;
    version = 1;
  };

  fetchpatch2 = callPackage ../build-support/fetchpatch {
    patchutils = buildPackages.patchutils_0_4_2;
  } // {
    tests = pkgs.tests.fetchpatch2;
    version = 2;
  };