!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

231 Members
75 Servers

Load older messages


SenderMessageTime
7 Mar 2023
@trofi:matrix.orgtrofiOh, it's really added via DT_NEEDED /o\17:55:54
@trofi:matrix.orgtrofi That looks very wrong. patchelf might not have shrunk NEEDED section size and spilled over to INTERP. I'll try to reproduce using qemu-user locally. 18:02:11
@winterqt:nixos.devWinter (she/her)Thank you! If you'd like, I can get an lddtree output sometime today.18:39:12
@winterqt:nixos.devWinter (she/her)* Thank you for looking into it! If you'd like, I can get an lddtree output sometime today.18:45:48
@winterqt:nixos.devWinter (she/her)though I suppose you don't need it since you can just get it with qemu-user18:45:59
@trofi:matrix.orgtrofi Yeah, x86_64-linux lddtree works as is on aarch64-linux binary from hydra and shows the same unexpected dependency. 19:35:49
@winterqt:nixos.devWinter (she/her)Got it, wasn't sure if lddtree used ldd or not.20:51:28
@winterqt:nixos.devWinter (she/her)Definitely odd that this only happens on aarch64-linux... are ELF headers really that different between the architectures?20:52:13
@trofi:matrix.orgtrofiMost header types are the same and mainly differ only by endianness or by field sizes (32 vs 64 bits). But some sections are architecture-specific, like relocations (.rela / .rela.dyn).22:15:13
@trofi:matrix.orgtrofi 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. 22:26:15
8 Mar 2023
@winterqt:nixos.devWinter (she/her)
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.
Where did you find this info? Now I'm curious why I don't see the stack check guard in e.g. Guix's hello binary 🤔
02:22:13
@winterqt:nixos.devWinter (she/her)Thanks for looking into it by the way02:22:23
@winterqt:nixos.devWinter (she/her)
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.
* Where did you find this info?
02:53:19
@vcunat:matrix.orgvcunat
In reply to @winterqt:nixos.dev
Where did you find this info?
That's the libc.so text-file.
07:23:25
@trofi:matrix.orgtrofi
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.

07:30:07
@trofi:matrix.orgtrofi
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.

07:36:32
@vcunat:matrix.orgvcunat
In reply to @winterqt:nixos.dev
Where did you find this info?
* That's the libc.so text-file.
08:09:19
14 Mar 2023
@ckie:ckie.devckie (they/them) changed their display name from ckie (they/them) to ckie (they/them; heavily limited keyboard usage, dictation or voice only).01:09:43
18 Mar 2023
@rick:matrix.ciphernetics.nlMindavi changed their display name from Rick (Mindavi) to Mindavi.10:48:18
20 Mar 2023
@hexa:lossy.networkhexa
❯ 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

15:07:53
@artturin:matrix.orgArtturinthe override clears the // { version ... } done on the callPackage result15:18:43
@artturin:matrix.orgArtturin
  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;
  };
15:18:47
@artturin:matrix.orgArtturinpassthru is not used here because fetchpatch retunrs a function15:19:10
@artturin:matrix.orgArtturin

one solution

diff --git a/pkgs/tools/networking/curl/default.nix b/pkgs/tools/networking/curl/default.nix
index fca190bde4a..b95275327c2 100644
--- a/pkgs/tools/networking/curl/default.nix
+++ b/pkgs/tools/networking/curl/default.nix
@@ -168,7 +168,7 @@ stdenv.mkDerivation (finalAttrs: {
     inherit opensslSupport openssl;
     tests = {
       withCheck = finalAttrs.finalPackage.overrideAttrs (_: { doCheck = true; });
-      fetchpatch = tests.fetchpatch.simple.override { fetchpatch = fetchpatch.override { fetchurl = useThisCurl fetchurl; }; };
+      fetchpatch = tests.fetchpatch.simple.override { fetchpatch = (fetchpatch.override { fetchurl = useThisCurl fetchurl; }) // { version = 1; }; };
       curlpp = useThisCurl curlpp;
       coeurl = useThisCurl coeurl;
       haskell-curl = useThisCurl haskellPackages.curl;
15:20:15
@hexa:lossy.networkhexaI'll take that, thanks15:29:21
@artturin:matrix.orgArtturinhttps://github.com/NixOS/nixpkgs/pull/222215 doesn't fix the issue either, don't know if there's a way to preserve it through .override15:38:54
@hexa:lossy.networkhexapushed the "one solution" one top of https://github.com/NixOS/nixpkgs/pull/22217215:51:33
@hexa:lossy.networkhexaw/e you prefer15:51:51
@hexa:lossy.networkhexa * pushed the "one solution" one on top of https://github.com/NixOS/nixpkgs/pull/22217216:31:36
23 Mar 2023
@ckie:ckie.devckie (they/them) changed their display name from ckie (they/them; heavily limited keyboard usage, dictation or voice only) to ckie (they/them; limited keyboard usage, voice preferred).02:03:47

Show newer messages


Back to Room ListRoom Version: 9