Binary from the website goes into an infinite startup loop on Arch

[AdamantGarth]

Please file an issue if you find that vkcube from your package manager works but binaries produced by this project do not.

While watching the talk about the "Year of the Linux Gaming Desktop", where this demo was presented, I tried to run it on Arch after downloading from here. It went into an infinite loop with forever expanding LD_PRELOAD (with another instance of libdl.so.2 libpthread.so.0 added to it on every iteration), despite the claims of it working on every distro forever :)

Here's the pastebin with logs: https://pastebin.com/0Eex2BaG. I captured only first 4096 characters of the output, but it gets HUGE.

And vkcube works fine, yeah.

[Cycatz]

Same issue here.

vkcube command works:

But static-window9 binary stuck and keep evecve-ing itself with the same library string "libdl.so.2 libpthread.so.0" appending to LD_PRELOAD

Here are the logs:

debug: detecting whether we are running in the dynamic linker
debug: we're not. detecting the dynamic linker path
debug: prepare to execve reload
debug: dyld_path=/lib64/ld-linux-x86-64.so.2
debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2

[tau-dev]

From my very limited testing, it seems that I just checked, and glibc ld-linux.so completely ignores the LD_PRELOAD envvar and the --preload switch when the binary looks static. The first possible cause I could find is that this may have been implemented intentionally to fix

[28648] dynamic-link: Running ld.so on statically linked binaries crashes

(https://sourceware.org/pipermail/libc-alpha/2022-February/136040.html) ... which looks like bad luck for us. Then again, it obviously worked on the older glibc versions in other distros, so if we find the patch that broke it, we may be able to work around it or submit an updated patch to glibc. Does anyone know where these bugs are tracked?

[nektro]

https://sourceware.org/bugzilla/buglist.cgi?product=glibc&component=dynamic-link

this is definitely an upstream regression