X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, a...@suse.de
El dv 26 de 01 de 2018 a les 20:10 +0100, Aurelien Jarno va escriure: > It's probably not clear, let me try again. Your package provides a > /lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2 symlink. As 2 > packages or more can't provide the same file, I conclude that to be able > to install your package your program interpreter should be installed in > /lib64 (and not in /lib), which is exactly what you want to avoid. You are forgetting the claim that the example is countering. No matter how, can a /lib/ld-linux-x86-64.so.2 program run on your system? Does the provided package work on your system or not? El dv 26 de 01 de 2018 a les 20:42 +0100, Samuel Thibault va escriure: > How did it find an interpreter? Now the workings; you may not like how it works, but it does. My kernel acknowledges the fact that third-party programs may require interpreters that do not exist, which is a problem if the base filesystem cannot be modified. If the interpreter does not exist, the kernel asks for alternatives. In the case of amd64, there is a module which handles the well-known /lib64/ld-linux-x86-64.so.2. If I want to support those programs, I load the module with the alternative /lib/ld-linux-x86-64.so.2. It is like a symlink, but without touching the base filesystem and just for the purpose of finding an interpreter. The way I see the ABIs, /lib64/ld-linux-x86-64.so.2, /lib/ld.so.1, /libexec/ld-elf.so.1, etc. are magic strings, not requirements for the filesystem. It is a kind of binfmt-support solution.
smime.p7s
Description: S/MIME cryptographic signature
