On 2025-04-14 18:44, Helmut Grohne wrote: > On Mon, Apr 14, 2025 at 05:23:01PM +0100, Simon McVittie wrote: >> Loaders are expected to be able to recognise that a particular driver is not >> for them, and gracefully not load it. In practice this works fine, because >> all >> of our architectures can be distinguished by their ELF headers (and if that >> wasn't the case, multiarch co-installation of ordinary shared libraries would >> go badly wrong). > > I'm sorry to disappoint you, but reality is not like that. > > You can actually run kfreebsd-amd64 binaries on a Linux kernel as their > ELF header looks the same. Not that they do useful stuff, but they may > go far enough as to reset your system clock. I've actually encountered > that. > > Then, if you combine armel and armhf, those architectures also have ELF > headers that are mostly indistinguishable. I'm not sure what happens > exactly, but it isn't good. > > What also gets interesting is when you try to combine e.g. amd64 and > musl-linux-amd64. Those also do not tell apart from their ELF header. > > The elf-arch tool from arch-test attempts to map ELF headers to Debian > architectures, but it can only do so much. > > So no, as long as we support armel and armhf simultaneously, we cannot > tell architectures apart by their ELF header. > > [...] > > Given what I said earlier about the inability to tell ELF headers apart > and the real problems observed in trying to do so, I have a preference > for the first option.
Given that different variants of libvulkan_*.so are located in separate search paths, is there any scenario other than a system misconfiguration which would result in an attempt to load the wrong one? -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
