[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Javier Serrano Polo changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #15 from Javier Serrano Polo --- There is a patch, thus wontfix is the right status.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #14 from Javier Serrano Polo --- (In reply to Adam Conrad from comment #13) > Please stop speaking as if you speak for the Debian toolchain maintainers, > or Debian as a whole. You don't. I do not represent Debian, but I state facts: multiarch interpreter names are officially supported in Debian. This is true because: 1. Multiarch interpreters are shipped in glibc packages of the stable release. 2. Programs compiled with multiarch interpreters work in Debian without further changes. 3. Multiarch interpreters are not the target of the traditional interpreter symlinks, thus they are not required for traditional programs. 4. Debian ldconfig takes care not to remove the multiarch interpreters. This is intentional, as you can read: /* Do not change the symlink pointer to the dynamic linker except for non-existing symlinks, as it might break multiarch systems. */ 5. Debian glibc maintainers are careful not to add files to their packages because that would mean they implicitly support the provided feature. So please have a look at the submitted patch.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #13 from Adam Conrad --- (In reply to Javier Serrano Polo from comment #12) > > Multiarch interpreter names are officially supported in Debian. No. No they're not. I don't think "officially" means what you think it means. I've asked you many times before, but I'll ask again, please stop dragging Debian into this. Debian multiarch intentionally does *not* break ABI. We recognize this is a limitation, in that some arches can't coexist due to conflicting ld.so paths, but that was better than the alternative. Please stop speaking as if you speak for the Debian toolchain maintainers, or Debian as a whole. You don't.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #12 from Javier Serrano Polo --- Created attachment 43357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43357&action=edit Initial support for multiarch interpreters (In reply to Marc Glisse from comment #11) > If you intend to send a patch, you can send it directly to > gcc-patc...@gcc.gnu.org, you don't need a bugzilla entry... Thank you, but Bugzilla helps with organization. Multiarch interpreter names are officially supported in Debian. Please have a look at this patch against GCC 6.3.0. It only supports x86 architectures, but it is simpler to review.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #11 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #10) > This report is about the patch that will be submitted with multiarch names. If you intend to send a patch, you can send it directly to gcc-patc...@gcc.gnu.org, you don't need a bugzilla entry...
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #10 from Javier Serrano Polo --- (In reply to Joseph S. Myers from comment #9) > Not a bug. The appropriate time to raise such an issue is if in future > there is otherwise consensus to have a major libc ABI break and move to > libc.so.7 SONAME, and the appropriate place is the mailing lists that have > such a discussion at that time. This report is about the patch that will be submitted with multiarch names. It is an enhancement request to support multiarch systems. It has nothing to do with whatever ABI breaks you believe may happen; libc.so.7 is not needed. If you do not understand this goal, status should be "unconfirmed". If you do, it should be "wontfix".
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Joseph S. Myers --- Not a bug. The appropriate time to raise such an issue is if in future there is otherwise consensus to have a major libc ABI break and move to libc.so.7 SONAME, and the appropriate place is the mailing lists that have such a discussion at that time.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Javier Serrano Polo changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from Javier Serrano Polo --- > the patch stands a chance of being accepted.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #7 from Adam Conrad --- (In reply to Javier Serrano Polo from comment #6) > > > the discussion about names is probably more appropriate on the libc side > > Adam, do you agree? I agree with this statement, sure. But I don't agree that there's any point in having the discussion. Essentially, you're asking for one of two possible things here, as I see it: 1) We come up with a new set of interpreter paths, and have a --break-abi-with-alternate-paths build option, or 2) We don't come up with any list, and have a --break-abi-with-arbitrary-interpreter=/path option. I don't see how providing options that encourage users to shoot themselves so readily in their feet is a useful thing to do. Sure, 99% of users never build either gcc or glibc, and thus this is entirely hidden to them, but I still don't see why the 0.0001% that deeply care about moving the interpreter on their system can't just patch glibc and gcc in the two places necessary to make that happen, rather than publishing a config interface that makes it look like a supportable option in the toolchains that define those ABIs.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #6 from Javier Serrano Polo --- > As long as the new behavior is optional (not the default), the patch stands a > chance of being accepted. Thank you. I will change the status of the report if you do not mind. > the discussion about names is probably more appropriate on the libc side Adam, do you agree?
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #5 from Adam Conrad --- (In reply to Javier Serrano Polo from comment #1) > Adam, if you had to come up with multiarch interpreter names for traditional > architectures, which would be the proper place to discuss? As Andrew says, the ABI is fixed. I understand that you run a kernel patch/module to alias interpreters to other paths, but this isn't something we can or should support upstream. If I had a time machine, I could give you a list of interpreter names I would have argued for two decades ago. I don't have a time machine and, thus, such a discussion is pointless and, frankly, now that you've dragged me into this in three different forums, tiresome.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #4 from Marc Glisse --- (In reply to Javier Serrano Polo from comment #3) > Upstream wants to make multiarch harder; the patch will not be posted here. As long as the new behavior is optional (not the default), the patch stands a chance of being accepted. But I am not sure what exactly this PR is for, asking to support names that haven't been decided yet. (the discussion about names is probably more appropriate on the libc side, since that's usually where ld.so comes from)
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 --- Comment #3 from Javier Serrano Polo --- Upstream wants to make multiarch harder; the patch will not be posted here. Nevertheless, Adam, please answer to my previous question.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The ABI is fixed so we cannot change it.
[Bug c/84173] Support glibc multiarch interpreter names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84173 Javier Serrano Polo changed: What|Removed |Added CC||adconrad at 0c3 dot net --- Comment #1 from Javier Serrano Polo --- Adam, if you had to come up with multiarch interpreter names for traditional architectures, which would be the proper place to discuss?
