Conversation

Notices

1. Embed this notice
   Tobias Hellgren (thanius@mastodon.chuggybumba.com)'s status on Thursday, 16-Jan-2025 00:50:36 JST Tobias Hellgren

   in reply to

   • Matthew Garrett

   @mjg59 Fucking computers is hardware porn

   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Thursday, 16-Jan-2025 00:50:37 JST Matthew Garrett

     in reply to

     Fucking computers, man

   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Thursday, 16-Jan-2025 00:50:38 JST Matthew Garrett

     in reply to

     Turns out that ldd doesn't run the rtld that's defined in the binary - it has a list of rtlds it tries to run against the binary. If I'd read the output more closely I'd have seen:

     /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f0c656cd000)

     The toolchain that built the binary set the rtld to a path in /lib, but ldd was reading it out of /lib64.The kernel only uses the built-in path, so we got ENOENT.

   • Embed this notice
     Matthew Garrett (mjg59@nondeterministic.computer)'s status on Thursday, 16-Jan-2025 00:50:40 JST Matthew Garrett

     Hit a *really* corner case bug today - a binary was absolutely present but returned ENOENT whenever you tried to run it. strace showed exevce() returning it, so it was happening when the kernel tried to run it. Normally I'd assume that the rtld (the thing that the kernel delegates loading of dynamic libraries to when running a dynamically linked binary) was missing, but ldd showed nothing missing - everything was resolved, including the rtld. WTF?