This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
El dl 05 de 02 de 2018 a les 07:01 +0100, Florian Weimer va escriure: > Please rephrase that in a way which separates what happens today from > what should happen in the future. We are still in the alpha on x86 example. What happens today on your systems: 1. Kernel starts the alpha emulator. 2. The emulator looks for /lib/ld-linux.so.2. 3. The program fails. What happens today on my systems: 1. Kernel starts the alpha emulator. 2. The emulator looks for /lib/ld-linux.so.2. 3. User has configured the emulator to redirect all file operations to /lib/ld-linux-alpha.so.2. 4. The program runs, but the path /lib/ld-linux.so.2 will not work as expected. What should happen in the future: 1. Kernel starts the alpha emulator. 2. The emulator looks for /lib/ld-linux.so.2. 3. User has configured the emulator to use /lib/ld-linux-alpha.so.2 as the interpreter, even if /lib/ld-linux.so.2 exists. 4. The program runs. What happens with multiarch binaries: 1. Kernel starts the alpha emulator. 2. The emulator looks for /lib/ld-linux-alpha.so.2. 3. The program runs. > Currently, the kernel maps both the ELF interpreter and the executable. > Do you intend to change that? The only ability I add to the kernel is to map an alternative interpreter if the requested one is not found. But we are deviating from the topic: what should the multiarch interpreter names be? I like Zack's view. It does not follow the current practice of using infixes, but multiarch filesystems become cleaner and interpreter names are unique easily.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |