Nixpkgs Stdenv - Public Room Timeline

	Nixpkgs Stdenv	225 Members
		72 Servers

Load older messages

Sender	Message	Time
7 Mar 2023
Winter (she/her)	* `[nix-shell:~]$ which hello /nix/store/nfzcdd26n8qs7dyh6kwz2hmp9rkppdcg-hello-2.12.1/bin/hello [nix-shell:~]$ patchelf --print-needed /nix/store/nfzcdd26n8qs7dyh6kwz2hmp9rkppdcg-hello-2.12.1/bin/hello libc.so.6 ld-linux-aarch64.so.1` anyone know why/where we add ldso to needed for (as far as I can tell) just aarch64? i can't get the same result on x86_64-linux, and I don't see any extra flags added via ld-wrapper that would cause this.	01:44:46
Winter (she/her)	e.g. grepped `NIX_DEBUG=7` logs and cannot find anything that would do this	02:19:48
@trofi:matrix.org	`patchelf --set-interpreter`	07:18:50
@trofi:matrix.org	`lddtree` from `pax-utils` might make it more obvious where `ld.so` comes from.	07:19:15
@trofi:matrix.org	`ld.wrapper` sets it in `pkgs/build-support/bintools-wrapper/ld-wrapper.sh: extraBefore+=("-dynamic-linker" "$NIX_DYNAMIC_LINKER_@suffixSalt@")`	07:20:01
Winter (she/her)	In reply to @trofi:matrix.org `patchelf --set-interpreter` i don't think that's true entirely (either that or patchelf is bugged on aarch64)? x86_64-linux also has the interpreter set, but `patchelf --print-needed` does not show it.	12:41:29
Winter (she/her)	which is why i ask, it just seems strange and nonobvious	12:41:49
Winter (she/her)	(by "true entirely" i mean that doesn't explain what i'm seeing here)	12:44:50
Winter (she/her)	i checked an aarch64-linux binary not from Nixpkgs and it doesn't have the interpreter in print-needed either, so i think that rules out being a patchelf issue	12:45:54
Winter (she/her)	i just don't know where else the interpreter would get added to needed other than in ld-wrapper, and i do not see it there	12:46:30
Winter (she/her)	just seems very very strange that this is only happening on aarch64 🙃	12:54:05
Winter (she/her)	apologies for the maybe nonsensical rambling trofi, but hopefully those clarifications make the issue(?) clear that it's not the interpreter i'm talking about. i really don't know where to go from here, though, so any help is appreciated. thank you!	15:37:24
@trofi:matrix.org	Do you have an 'lddtree' output on problematic file? Does it show ldso output anywhere except the interpreter?	17:45:31
@trofi:matrix.org	I generally have less faith in patchelf than readelf or objdump when it comes to parsing elves.	17:49:47
@trofi:matrix.org	Oh, it's really added via DT_NEEDED /o\	17:55:54
@trofi:matrix.org	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
Winter (she/her)	Thank you! If you'd like, I can get an lddtree output sometime today.	18:39:12
Winter (she/her)	* Thank you for looking into it! If you'd like, I can get an lddtree output sometime today.	18:45:48
Winter (she/her)	though I suppose you don't need it since you can just get it with qemu-user	18:45:59
@trofi:matrix.org	Yeah, `x86_64-linux` `lddtree` works as is on `aarch64-linux` binary from hydra and shows the same unexpected dependency.	19:35:49
Winter (she/her)	Got it, wasn't sure if lddtree used ldd or not.	20:51:28
Winter (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.org	Most 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.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.	22:26:15
8 Mar 2023
Winter (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
Winter (she/her)	Thanks for looking into it by the way	02:22:23
Winter (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	In reply to @winterqt:nixos.dev Where did you find this info? That's the libc.so text-file.	07:23:25
@trofi:matrix.org	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.org	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

Show newer messages

Back to Room ListRoom Version: 9