Bug#888073: glibc: Support amd64 systems without /lib64
Hi, On Tue, 30 Jan 2018, Javier Serrano Polo wrote: > > But I fear for /lib64/ld-linux-x86-64.so.2 it's too late, > > It is never too late. Nowadays, there are no interoperability problems, > as I have proved in this bug report. hmm? Here let me show you the interop problem with your suggestion: % gcc -Wl,-dynamic-linker,/lib/ld-linux-x86-64.so.2 -o hello ~/src/hello.c % readelf -l hello | grep Reque [Requesting program interpreter: /lib/ld-linux-x86-64.so.2] % ./hello bash: ./hello: No such file or directory % ls /lib/ld-linux-x86-64.so.2 ls: cannot access /lib/ld-linux-x86-64.so.2: No such file or directory > Let us wait for your users to > complain about manually creating a symlink. So, uhm, you think it's acceptable to force everyone else to create a symlink because it's not acceptable to you? Ciao, Michael.
Bug#888073: glibc: Support amd64 systems without /lib64
Hi, On Tue, 30 Jan 2018, Javier Serrano Polo wrote: > El dl 29 de 01 de 2018 a les 16:24 +0000, Michael Matz va escriure: > > Is does, but draft means many things, and for the psABI doesn't include > > "making backward incompatible changes is okay". > > I am asking people to be nice, not requiring them to modify their > systems. Let me try a new proposal: > > 5.2.1 > Systems conforming to the AMD64 ABI may want to support > the /lib/ld-linux-x86-64.so.2 path name, which is preferred in > multiarch. > > Appendix A.1 > Systems conforming to the AMD64 ABI may want to support > lib/x86_64-linux-gnu subdirectories for the libraries, which are > preferred in multiarch. > > This way, people that want to help will not be frowned upon. > Could you do another assessment? I think the addition to A.1 along the above lines would be fine. But the change of 5.2.1 really can't be done. Yes, the above wording makes it optional, so it sounds harmless, but it isn't, for the reasons I already called out: as soon as we allow executables with /lib/ld-linux-x86-64.so.2 as PT_INTERP to be conforming (even optionally) we split the world (into those that do support it, as allowed, and those that don't, as also allowed). That must not happen. We could fix that split by not only allowing, but instead _requiring_ that new name to exist on all conforming implementations. Then the world won't be split, but it entails changes for everyone wanting to conform to the (newest version of the) psABI for dubious benefit, and so isn't something we would want either. Perhaps we still can do something about the x32 program interpreter (currently defined to sit in /libx32/ld-linux-x32.so.2). That is a relatively young addition and not many people use x32, so that could be moved to /lib to not repeat the problem of forcing a /libx32 directory on everyone even if they have other mechanisms. But I fear for /lib64/ld-linux-x86-64.so.2 it's too late, it'd create larger problems (conforming programs not starting everywhere conforming) than it fixes (the cosmetic problem of a mostly empty /lib64 directory having to exist). Ciao, Michael.
Bug#888073: glibc: Support amd64 systems without /lib64
Hi, On Mon, 29 Jan 2018, Javier Serrano Polo wrote: > El dl 29 de 01 de 2018 a les 13:43 +0000, Michael Matz va escriure: > > To see why that is so suppose I'm changing my compiler to use a different > > calling convention in which the first argument is passed in %rsi and the > > second in %rdi, and otherwise it's all the same. > > Could you tell me why on earth would you want to do that? Is there any > speed advantage? No, of course not. It was an easy to understand change to demonstrate a point I was trying to make. Obviously I failed. If I had known that you'd be triggered by the senselessness of the proposal I'd have made a different one: making some of the floating point regs be callee saved, which indeed would help benchmarks quite some. The way it's now (everything caller saved) is actually an artifact of the first implementations of the x86-64 insn set, and in retrospect was not the best choice. We _still_ won't make a change like that, even though it'd have a comparatively large advantage. > You are comparing a function-calling convention with a > filesystem requirement. No, I compared an ABI change with an ABI change. > There is an interest in dropping /lib64 and > maintain interoperability, and I find it legitimate. Dropping /lib64 basically means dropping interoperability. > > I recompile my whole system and I adjust all the various assembler > > snippets that have it hard-coded. > > Yet another person that believes I must recompile my whole system. > > > Does it make > > sense to encode this new calling convention in the psABI? > > Give me the reason for the new calling convention and I will tell you > whether it makes sense. You realized that this was a rhethoric question, right? I assume so from you removing my "No.", so what's your point? > > So, while you might say that putting the loader into an alternative path > > is a maintainers choice, it's a (badly advised) maintainers choice of not > > following the psABI, not a good reason to change it. > > Cleaner filesystem and multiarch simplicity. We have different views of > what constitutes good advice. Obviously. > > So, no, we can't change the psABI in that respect without > > repercussions for all systems claiming to be conforming, which is a > > bad idea for an ABI that's already nearly 20 years old. > > Sorry, I thought "Draft Version" meant to be a draft. Is does, but draft means many things, and for the psABI doesn't include "making backward incompatible changes is okay". > Also, I must have misunderstood the following: > > The System V Application Binary Interface will evolve over time > to address new technology and market requirements, and will be > reissued at intervals of approximately three years. Each new > edition of the specification is likely to contain extensions and > additions that will increase the potential capabilities of > applications that are written to conform to the ABI. Indeed. We should probably remove this paragraph. > The only repercussion you are talking about is that systems will not be > able to make a claim if they do not adapt to the new version. There are > no real interoperability issues, as my previous counterexample proves. You gave no counterexamples. You explained the interop problems away by stating that "non-evolving" systems merely need to not claim compatibility with the newest version and all will be fine. > I guess it is too much for distros to ship a symlink that would help > Debian-based systems to get rid of /lib64. Yes, it is. We basically need to make a choice between two things: (a) change the psABI -> debian can get rid of /lib64 (but see below), everybody else needs to add the new loader name (at least if they want to "evolve"), or (b) don't change the psABI -> no changes anywhere A change in an psABI necessarily needs to have a very high barrier to entry, so it needs to have some very sound and large advantages. Let's look at the advantage of (a): debian can get rid of a filename (and possibly directory), everybody else needs to add a filename. Even that doesn't sound like a very large advantage considering everything. But debian can't _actually_ get rid of the dir and filename, because not all software is compiled on debian, so 3rd party software conceivably would continue to use the current loader name. In the name of cleanliness you probably would move that "old" loader name into some new subpackage of glibc so that you only need it when such 3rd party apps are actually installed. But still you wouldn't be able to get rid of it wholly. So now you've made an ABI change that resulted in adding a name for every
Bug#888073: glibc: Support amd64 systems without /lib64
Hi, On Fri, 26 Jan 2018, Javier Serrano Polo wrote: > It would be nice if you answered the question about appendix A.1. > > So, we have five people who state or imply that either my amd64 systems > do not exist or they are unavoidably incompatible with systems depending > on a /lib64 directory. > > My systems obviously exist. To the claim that I cannot run a /lib64 > program without rebuilding, the answer is easy to say: try my system. To > the claim that applications from my system will not run anywhere else, I > can provide a counterexample: you can install the attached package. > > Would you accept the evidence? Is /lib64 still a mistake or rather a > maintainer's choice? Just because your system works fine with deviations from the psABI (as it contains code or data to make it work with these deviations) doesn't imply that any changes in the psABI are required or advised. To see why that is so suppose I'm changing my compiler to use a different calling convention in which the first argument is passed in %rsi and the second in %rdi, and otherwise it's all the same. I recompile my whole system and I adjust all the various assembler snippets that have it hard-coded. I will end up with a system that works fine; just like you. Does it make sense to encode this new calling convention in the psABI? No. The whole point of a defined psABI is that you can move an executable from one compatible system to another different but also psABI-compatible system and rightfully expect that to work (given further constraints, of course). Encoding alternatives for the dynamic loader into the psABI defeats this purpose. A psABI-compliant system then suddenly wouldn't only have to provide /lib64/ld-linux-x86-64.so.2, but also your proposed file; i.e. alternatives in an ABI are actually additional requirements on the system (they're alternatives only for a particular file). If a system wouldn't do that then it can't claim to be psABI-compatible anymore as there would exist executables which can't be loaded on it. So, while you might say that putting the loader into an alternative path is a maintainers choice, it's a (badly advised) maintainers choice of not following the psABI, not a good reason to change it. This is slightly different from the choice of not following the suggestion in the psABI of putting libraries into **/lib64, like the multiarch approach is doing. It is different because these path names are configurable as search paths in the loader configuration files (and were already configurable at the time multiarch was invented) and not directly encoded into the ELF files. (Ignoring DT_RPATH and DT_RUNPATH of course). So, no, we can't change the psABI in that respect without repercussions for all systems claiming to be conforming, which is a bad idea for an ABI that's already nearly 20 years old. Ciao, Michael.
