zig relies too much on /usr/bin/env to detect dynamic-linker path

[mikdusan]

Zig Version

0.11.0-dev.1580+a5b34a61a

Steps to Reproduce and Observed Behavior

• on linux system with static /usr/bin/env try to produce hello.zig executable linked with -lc
• we use stage2 exe to diagnose because stage3 cannot be built
• tldr; missing command line option -dynamic-linker /lib/ld-musl-x86_64.so.1

$ zig2 build-exe hello.zig -lc --verbose-link
LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jerem
y/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o

Expected Behavior

• has command line option -dynamic-linker /lib/ld-musl-x86_64.so.1

$ zig2 build-exe hello.zig -lc --verbose-link
LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o -dynamic-linker /lib/ld-musl-x86_64.so.1 --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jerem
y/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o

[mikdusan]

related IRC transcript

2023-02-05 20:43:56 jhuntwork   hey all, still can't build a working stage3 zig on this host for some reason - I thought I'd try the bootstrap method to rule out my host compiler
2023-02-05 20:44:13 jhuntwork   I get through the first host llvm and zig and then the produced zig is broken
2023-02-05 20:44:17 jhuntwork   Check for working C compiler: /home/jeremy/zig-bootstrap/out/host/bin/zig - broken
2023-02-05 20:44:36 jhuntwork   running that directly still produces a segfault and this shows up in dmesg
2023-02-05 20:44:55 jhuntwork   zig[21700]: segfault at 0 ip 0000000000000000 sp 00007fff2269ceb8 error 14 in zig[200000+2c43000] likely on CPU 4 (core 0, socket 0)
2023-02-05 20:45:03 jhuntwork   Code: Unable to access opcode bytes at 0xffffffffffffffd6.
2023-02-05 20:46:17 jhuntwork   invoked the bootstrap with: CMAKE_GENERATOR=Ninja ./build native-linux-musl baseline
2023-02-05 20:46:38 jhuntwork   it's an x86_64 machine
...
...
...
2023-02-06 10:12:50	jhuntwork	ifreund: using the statically linked zig resulted in a stage3 zig that segfaults again
2023-02-06 10:15:15	ifreund	jhuntwork: are you getting any kind of useful stacktrace? Are you building it in debug mode?
2023-02-06 10:17:19	jhuntwork	building in debug, yes. no stack trace at all the last time i looked, it's exiting immediately (can't even produce help output)
2023-02-06 10:17:24	jhuntwork	will check again on this latest binary
2023-02-06 10:17:27	freshcoffee	jhuntwork: this was a custom distro right?
2023-02-06 10:17:45	freshcoffee	*linux distro
2023-02-06 10:17:49	jhuntwork	yah
2023-02-06 10:18:01	ifreund	hmm, strace maybe?
2023-02-06 10:18:10	ifreund	or valgrind?
2023-02-06 10:18:16	jhuntwork	so problem could totally be in my llvm, but it's odd because I've noticed no issues with anything else
2023-02-06 10:18:37	jhuntwork	will try strace, don't have valgrind available just yet, but could investigate that too
2023-02-06 10:18:37	ifreund	zig does use a lot more of llvm than most projects
2023-02-06 10:18:50	ifreund	it also links libclang and lld
2023-02-06 10:19:12	freshcoffee	ip 0000 is concerning. it sounds like something is wrong with main entry
2023-02-06 10:20:05	jhuntwork	I was originally using mold as my linker, though lld was still available as well as liblld
2023-02-06 10:20:34	jhuntwork	used that to build llvm, but I think the last build I switched back to lld
2023-02-06 10:21:14	freshcoffee	you get a zig2.exe which is an artifact of system toolchain; but it's zig.exe (ie: zig3) that fails
2023-02-06 10:21:23	jhuntwork	yes
2023-02-06 10:21:31	freshcoffee	can you use zig2.exe to build-exe hello.zig, does that work?
2023-02-06 10:21:37	jhuntwork	checking
2023-02-06 10:22:32	jhuntwork	will take a few minutes, need to rebuild
2023-02-06 10:25:01	freshcoffee	and is this a glibc or musl based distro?
2023-02-06 10:25:06	jhuntwork	musl
2023-02-06 10:25:23	jhuntwork	https://github.com/jhuntwork/merelinux - for recipes
2023-02-06 10:26:26	ifreund	nice, another linux that isn't GNU/Linux
2023-02-06 10:27:02	jhuntwork	freshcoffee: think you pointed out an oddity of libgcc_s and unwind there, I could be wrong but don't think that's releated, libgcc_s is just a symlink to libunwind for sources that are determined to look for it
2023-02-06 10:28:21	jhuntwork	ifreund: not sure if that's a good "nice" ... :)
2023-02-06 10:29:19	freshcoffee	and system musl and other libs are available as .so ?
2023-02-06 10:30:29	jhuntwork	$ /lib/libc.so
2023-02-06 10:30:29	jhuntwork	musl libc (x86_64)
2023-02-06 10:30:29	jhuntwork	Version 1.2.3
2023-02-06 10:30:48	jhuntwork	may only have static llvm though
2023-02-06 10:30:54	freshcoffee	that sounds fine
2023-02-06 10:31:07	ifreund	jhuntwork: I'm definitely not a fan of GNU code myself, planning to switch to https://chimera-linux.org on my laptop at least once the alpha is released 
2023-02-06 10:31:31	jhuntwork	nice
2023-02-06 10:31:39	freshcoffee	^^ i see what you did there
2023-02-06 10:31:52	jhuntwork	:)
2023-02-06 10:32:31	jhuntwork	right now, mere uses pacman, but my intention was to write a new PM using zig, based somewhat on pacman, but without a lot of the dependencies that I dislike
2023-02-06 10:32:36	freshcoffee	chrimera interesting. I don't think I've seen someone use a bsd userland on linux with musl
2023-02-06 10:32:39	jhuntwork	like gpg and bash for the build system
2023-02-06 10:32:41	freshcoffee	*chimera
2023-02-06 10:34:17	ifreund	yeah, bsd userland is soo much better than busybox for usability
2023-02-06 10:34:34	jhuntwork	zig2 can build a usable hello.zig
2023-02-06 10:34:51	ifreund	jhuntwork: can it still do so if you link libc? -lc
2023-02-06 10:35:10	freshcoffee	can you nuke zig-cache and pastie.bin: `zig2 build-exe hello.zig --verbose-link`
2023-02-06 10:36:09	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -static -o hello hello.o /home/jeremy/.cache/zig/o/59d072d93b39432cc34d1657717d1be9/libc.a --as-needed /home/jeremy/.cache/zig/o/ee99b332c747ab8f7a61025c6fb45cc6/libcompiler_rt.a
2023-02-06 10:36:46	ifreund	that's missing the C runtime library stuff isn't it
2023-02-06 10:37:08	jhuntwork	how do I add -lc to the build command?
2023-02-06 10:37:11	freshcoffee	and then ifreund's variation: `zig2 build-exe hello.zig -lc --verbose-link`
2023-02-06 10:37:16	jhuntwork	thanks
2023-02-06 10:37:30	ifreund	jhuntwork: easier to just use zig build-exe directly, otherwise you'd have to edit the build.zig
2023-02-06 10:37:41	jhuntwork	that segfaulgs
2023-02-06 10:37:51	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o
2023-02-06 10:38:10	freshcoffee	and `zig env` ?
2023-02-06 10:38:26	freshcoffee	err `zig2 env` ?
2023-02-06 10:41:23	freshcoffee	huh. I don't see a `-dynamic-linker` option in the last link line
2023-02-06 10:41:37	jhuntwork	https://pastebin.mozilla.org/RXaUf78r
2023-02-06 10:42:29	ifreund	is `zig2 build-exe hello.zig -lc -dynamic --verbose-link` any different?
2023-02-06 10:42:55	jhuntwork	checking
2023-02-06 10:43:42	jhuntwork	it also segfaults, here is the link line
2023-02-06 10:43:43	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o
2023-02-06 10:43:55	jhuntwork	looks the same
2023-02-06 10:44:27	jhuntwork	-static works
2023-02-06 10:44:30	jhuntwork	usable bin
2023-02-06 10:44:47	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -static -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o --as-needed --start-group -lm -lpthread -lc -ldl -lrt -lutil --end-group /home/jeremy/.cache/zig/o/bf540ff7f2239ed2e536b0f4221e2245/libcompiler_rt.a /lib/crtn.o
2023-02-06 10:45:34	jhuntwork	which I don't mind, kind of wanted a static zig anyway, but would be nice to understand why 
2023-02-06 10:46:36	ifreund	hmm, does explicitly specifying the path to your dynamic linker with --dynamic-linker fix it?
2023-02-06 10:46:44	jhuntwork	checking
2023-02-06 10:47:16	jhuntwork	yep :)
2023-02-06 10:47:25	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib -dynamic-linker /lib/libc.so hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/8cb6d0e313485831a8fed78921d4e9ae/libcompiler_rt.a /lib/crtn.o --allow-shlib-undefined
2023-02-06 10:47:44	freshcoffee	as a baseline, take the exact LLD link command line that produces crashing hello.exe, and prefix with `zig2 ld.lld ....` and in there add `-dynamic-linker /lib/ld-musl-x86_64.so.1`
2023-02-06 10:47:55	freshcoffee	wait... you used libc.so as dynamic linker? 
2023-02-06 10:48:15	jhuntwork	$ ls -l /lib/ld-musl-x86_64.so.1
2023-02-06 10:48:16	jhuntwork	lrwxrwxrwx    1 root     root            12 Sep 25 16:20 /lib/ld-musl-x86_64.so.1 -> /lib/libc.so
2023-02-06 10:48:20	freshcoffee	ha
2023-02-06 10:49:10	freshcoffee	is that some kind of optimization? I am looking at alpine linux right now, and it does not have a linked ld-musl-x86_64-.so.1
2023-02-06 10:49:33	jhuntwork	I think that is the default behavior of 'make install' musl's build system
2023-02-06 10:49:37	freshcoffee	oh never mind. they did it backwards. /usr/lib/libc.so -> /lib/ld-musl lol
2023-02-06 10:50:23	jhuntwork	checking the baseline request cmd
2023-02-06 10:50:27	freshcoffee	ok so question is why doesn't `-dynamic` do anything. Can you show output of `zig2 build-exe hello.zig -lc -dynamic --verbose-link` 
2023-02-06 10:50:36	jhuntwork	ok
2023-02-06 10:51:11	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o
2023-02-06 10:51:29	ifreund	this comment is wrong: https://github.com/ziglang/zig/blob/a5b34a61ab61882bf55d87e4cbc8186215ecf320/lib/std/zig/system/NativeTargetInfo.zig#L263
2023-02-06 10:51:58	ifreund	not sure if the code is actually incorrect though
2023-02-06 10:52:09	freshcoffee	output of `zig2 build-exe -lc --show-builtin | grep -i link`
2023-02-06 10:52:51	jhuntwork	$ ./zig2 build-exe -lc --show-builtin | grep -i link
2023-02-06 10:52:52	jhuntwork	pub const link_mode = std.builtin.LinkMode.Dynamic;
2023-02-06 10:52:52	jhuntwork	pub const link_libc = true;
2023-02-06 10:52:52	jhuntwork	pub const link_libcpp = false;
2023-02-06 10:53:11	freshcoffee	good news is `-dynamic` is definitely not required
2023-02-06 10:54:10	jhuntwork	yah, the -static was encouraging
2023-02-06 10:54:54	freshcoffee	i meant re: was that preventing `-dynamic-linker` and we can rule out link_mode as the problem
2023-02-06 10:56:29	jhuntwork	btw, the 'baseline' command, just adding in the -dynamic-linker arg works
2023-02-06 10:58:09	jhuntwork	./zig2 ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -dynamic-linker /lib/ld-musl-x86_64.so.1 -L /lib hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o
2023-02-06 11:01:48	freshcoffee	curious to output of `ldd /usr/bin/env`
2023-02-06 11:02:17	jhuntwork	/usr/bin/env is probably a symlink to busybox which is a static binary - but I can choose another one if you like that is dynamic
2023-02-06 11:02:39	jhuntwork	$ ldd /usr/bin/env
2023-02-06 11:02:40	jhuntwork	ldd: /usr/bin/env: Not a valid dynamic program
2023-02-06 11:02:49	freshcoffee	zig under certain circumstances probes that file for dynamic info and it may be a factor here
2023-02-06 11:02:50	jhuntwork	$ file /usr/bin/env
2023-02-06 11:02:51	jhuntwork	/usr/bin/env: symbolic link to /bin/busybox
2023-02-06 11:03:05	jhuntwork	$ file /bin/busybox
2023-02-06 11:03:05	jhuntwork	/bin/busybox: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
2023-02-06 11:08:07	jhuntwork	https://github.com/ziglang/zig/blob/master/lib/std/zig/system/NativeTargetInfo.zig#L244
2023-02-06 11:08:33	freshcoffee	i don't know if what ifreund linked to is in play; it seems to me that is only for cross-target mode which shouldn't be active
2023-02-06 11:08:51	freshcoffee	right now I'm still guessing that /usr/bin/env is the issue
2023-02-06 11:08:54	ifreund	yeah, it shouldn't be hitting that code path in this case
2023-02-06 11:10:04	jhuntwork	why try to find the dynamic linker from an binary in the fs, why not ask the compiler?
2023-02-06 11:11:59	jhuntwork	echo 'int main(void){return 1;}' | clang -x c -
2023-02-06 11:12:03	jhuntwork	readelf -l a.out | grep interpreter [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
2023-02-06 11:14:53	freshcoffee	before going down this road further,
2023-02-06 11:16:43	freshcoffee	could you hack NativeTargetInfo.zig and replace the 1 occurance of "/usr/bin/env" with a suitable, simple dynamic elf file and rebuild zig2
2023-02-06 11:16:59	jhuntwork	yeah, for sure, let me find an example
2023-02-06 11:17:51	freshcoffee	maybe even `/usr/lib/libc.so` 
2023-02-06 11:17:57	jhuntwork	/usr/bin/python will work 
2023-02-06 11:19:04	jhuntwork	building
2023-02-06 11:19:24	freshcoffee	what I'm looking for is a confirm: if changing to a valid dynamic exe, does `zig2 build-exe hello.zig -lc --verbose-link` 1. contain `-dynamic-linker` and 2. hello.exe does not crash
2023-02-06 11:20:06	jhuntwork	sounds good
2023-02-06 11:20:30	freshcoffee	also curious; why is busybox static on your distro. For comparison, on alpine it is dynamic
2023-02-06 11:21:30	jhuntwork	because I wanted a static busybox :) it's been useful in some scenarios for getting a useful tool as a single file available in an image or container
2023-02-06 11:23:19	jhuntwork	for a lot of the core system things and pieces needed for running a service, I've been building static binaries, but for more general or desktop related tools, or things that have a lot of dependencies that will need to be updated frequently I'm going dynamic
2023-02-06 11:23:23	freshcoffee	heh wow. busybox is just an entire userland. wget? busybox! 
2023-02-06 11:24:02	jhuntwork	pretty much, it's not the best possible suite of tools, but it provides a usable enough base
2023-02-06 11:24:26	plumeus	When will Busybox support being compiled with musl without patches? Still waiting.
2023-02-06 11:25:13	freshcoffee	wait. here's the solve: `ln -s busybox zig` :)
2023-02-06 11:25:43	jhuntwork	heh
2023-02-06 11:31:05	jhuntwork	$ ./zig2 build-exe ../test/standalone/hello_world/hello.zig -lc --verbose-link
2023-02-06 11:31:06	jhuntwork	LLD Link... ld.lld --error-limit=0 -O0 -z stack-size=16777216 --gc-sections -znow -m elf_x86_64 -o hello /lib/crt1.o /lib/crti.o -L /lib -dynamic-linker /lib/ld-musl-x86_64.so.1 hello.o --as-needed -lm -lpthread -lc -ldl -lrt -lutil /home/jeremy/.cache/zig/o/78513c6bfd7c57d2aac0a0ce8d9f3e76/libcompiler_rt.a /lib/crtn.o
2023-02-06 11:31:15	jhuntwork	$ ./hello
2023-02-06 11:31:16	jhuntwork	Hello, World!
2023-02-06 11:31:19	freshcoffee	neato
2023-02-06 11:31:23	ifreund	I also question the motivation for snooping /bin/env to determine the dynamic linker path rather than interrogating cc
2023-02-06 11:31:27	jhuntwork	also, the stage3 fully works now
2023-02-06 11:31:44	jhuntwork	yay, I helped pinpoint an issue :D
2023-02-06 11:31:58	jhuntwork	my system isn't necessarily completely wonky :)
2023-02-06 11:32:04	jhuntwork	only somewhat wonky
2023-02-06 11:32:27	ifreund	it's just the first system with a statically linked /bin/env that someone's tried zig on :D
2023-02-06 11:32:35	freshcoffee	so /etc/issue is "Welcome to Wonky Linux 1.0"
2023-02-06 11:32:40	jhuntwork	lol
2023-02-06 11:32:59	jhuntwork	welp, glad I could help
2023-02-06 11:33:36	freshcoffee	so yeah now how to fix. I've been working on a config/probe framework for sometime to do these things, and cache the answers,
2023-02-06 11:33:36	jhuntwork	and also, if any of you are interested in helping me build out a nicer distro, friendly to zig... help is very welcome
2023-02-06 11:33:56	freshcoffee	this would allow for more "costly" but correct answers because cache
2023-02-06 11:34:07	freshcoffee	but lazy me gets stopped at.. wait.. I need regex for this
2023-02-06 11:35:07	freshcoffee	jhuntwork: what's your system compiler? gcc or clang
2023-02-06 11:35:12	jhuntwork	clang
2023-02-06 11:35:24	jhuntwork	I do have gcc available in /opt if needeed, but I try to avoid it
2023-02-06 11:35:56	jhuntwork	in fact, the only thing that requires it right now is syslinux - trying to maybe find a better boot loader, just don't want to use grub2 though :/
2023-02-06 11:39:27	freshcoffee	hmm... anyone know how long gcc and clang have supported the `-###` option ? it may be the lowest-runtime-cost to determining dynamic-linker path
2023-02-06 11:40:23	jhuntwork	doest that option require additional args? it doesn't give me the linker path here
2023-02-06 11:40:31	freshcoffee	jhuntwork: does this show -dynamic-linker option? `echo "" | cc -x c - -### |& grep dynamic`
2023-02-06 11:41:03	jhuntwork	ah, yes
2023-02-06 11:42:36	jhuntwork	stepping away for a while - thanks much for the help
2023-02-06 11:42:44	freshcoffee	yeah so this is prob reason why reading a file is preferred. Every zig invoke to link-a-thing (compile-a-thing too?) gathers this info. it's not cached.
2023-02-06 11:45:39	jhuntwork	I would say it would be much rarer for the compiler itself to be static, could check that, i.e., $(command -v cc)
2023-02-06 11:49:25	freshcoffee	ldd `which ldd`
2023-02-06 11:50:02	freshcoffee	for linux (elf) platforms, is ldd ubiquitous
2023-02-06 11:51:48	jhuntwork	I would think so, also on my system...
2023-02-06 11:51:48	jhuntwork	$ file /usr/bin/ldd
2023-02-06 11:51:49	jhuntwork	/usr/bin/ldd: symbolic link to /lib/libc.so
2023-02-06 11:51:59	jhuntwork	although, I think on alpine it's a wrapper script
2023-02-06 11:52:43	freshcoffee	maybe we try with 2 executables in this order: { /usr/bin/ldd, /usr/bin/env } and can stop at first one that gives the info
2023-02-06 11:54:16	jhuntwork	nice :) thanks again
2023-02-06 11:54:18	freshcoffee	oh yeah. that's an exec script. I think the zig logic only handles shebang 
2023-02-06 11:54:27	freshcoffee	jhuntwork: no probs. I'll open an issue on this

key takeaways

• todo: enhance dynamic-linker path system detection
• todo: possibly enhance dynamic-linker "defaults" when system detection fails

[ifreund]

The code attempts to fall back to a reasonable default with defaultAbiAndDynamicLinker() but this doesn't seem to be working in this case. It would be good to figure out why.

[rzezeski]

Hi, I've been admiring Zig from afar for the last couple of years and am now finally giving it some real time -- thanks for all the hard work.

For the last week I've been bringing-up zig-0.11.0 on illumos (specifically OmniOS). I ran into a similar issue as described in this ticket. illumos runs a multi-lib environment, and currently /usr/bin/env is still 32-bit. So when I try to build the zig compiler as 64-bit I get the 32-bit dynamic-linker instead of the 64-bit one and the OS immediately SIGKILLs the process when attempting to exec. I was able to easily work around that for the time being by pointing to a different executable, but that's a hack.

Coming back to this issue today my plan is to write a patch to hard-code the .solaris tag to use the default path as there is really nothing to detect, it's always the same environment. However, while auditing the code I noticed something weird: when requesting a "native" target zig always detects the ABI as GNU. I believe I traced the problem down to this code that builds the "all ABIs" list.

    for (all_abis) |abi| {
        // This may be a nonsensical parameter. We detect this with
        // error.UnknownDynamicLinkerPath and skip adding it to `ld_info_list`.
        const target: Target = .{
            .cpu = cpu,
            .os = os,
            .abi = abi,
            .ofmt = ofmt,
        };
        const ld = target.standardDynamicLinkerPath();
        if (ld.get() == null) continue;

        ld_info_list_buffer[ld_info_list_len] = .{
            .ld = ld,
            .abi = abi,
        };
        ld_info_list_len += 1;
    }

The problem is that the comment above the target initializer is no longer true (the UnknownDynamicLinkerPath error no longer exists and it seems this list is not filtered anymore). It creates a nonsensical combination of solaris ld + GNU ABI and the abiAndDynamicLinkerFromFile() later matches against this pair and figures the ABI must be GNU. Like I said, for illumos I don't think doing any of this detection makes sense and I'll hard-code it, but I wonder if this could be a footgun for other environments where it matches against the wrong ABI because of bogus combinations in the all_abis list.

[git-bruh]

The code attempts to fall back to a reasonable default with defaultAbiAndDynamicLinker() but this doesn't seem to be working in this case. It would be good to figure out why.

Seems like the code goes returns the value of abiAndDynamicLinkerFromFile rather than defaultAbiAndDynamicLinker

zig/lib/std/zig/system/NativeTargetInfo.zig

Line 362 in 402468b

if (!mem.startsWith(u8, line, "#!")) break :blk file;

after the break statement, the same statically linked /usr/bin/env file is passed to abiAndDynamicLinkerFromFile, which somehow concludes that the target does need a .interp entry

[git-bruh]

@ifreund Is it a sensible fix to make abiAndDynamicLinkerFromFile return an error when the ELF passed to it is actually a static binary, i.e. doesn't have the DT_* sections? Then the error path will get triggered in detectAbiAndDynamicLinker and actually return the default interp for the given target

[git-bruh]

@rzezeski Seems like the all_abis filtering is also what's causing the second half of the issue described here #17123, where built zig has native target of musl and you use it to build on glibc

But in this particular case, it eventually boils down to there being no portable and non-hacky way to determine at runtime whether zig's actual "native" is musl or glibc.. hmm

[ifreund]

@ifreund Is it a sensible fix to make abiAndDynamicLinkerFromFile return an error when the ELF passed to it is actually a static binary, i.e. doesn't have the DT_* sections? Then the error path will get triggered in detectAbiAndDynamicLinker and actually return the default interp for the given target

That sounds very reasonable to me.

[BratishkaErik]

More examples:

• Segmentation fault by default due to a wrong dynamic linker on KissLinux #21963
• Neither way can build zig w/o SegFault #21941