[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 #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 #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 go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 Adam Conrad adconrad at 0c3 dot net changed: What|Removed |Added CC||adconrad at 0c3 dot net --- Comment #4 from Adam Conrad adconrad at 0c3 dot net --- No, this is specifically about powerpc-linux-gnu. powerpc64le works fine. As for the library path questions, this first came up in runtime bug reports, and has been confirmed by many on clean chroots, so no, there aren't random libraries kicking around from other builds. doko's stack-protector discovery makes perfect sense as to why this works fine on Debian but not Ubuntu, as that's really the only difference between our two toolchains. Now, the question is *why*, and why only on ppc32? (Or maybe only on big-endian PPC, neither of us has tested a powerpc64-linux-gnu build yet).
[Bug target/65670] [5 Regression] missing libstdc++ symbols on powerpc64le-linux-gnu and arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65670 Adam Conrad adconrad at 0c3 dot net changed: What|Removed |Added CC||adconrad at 0c3 dot net --- Comment #9 from Adam Conrad adconrad at 0c3 dot net --- Testing in an Ubuntu 15.04 chroot with the latest distro 4.9 and the latest 5.0 from Matthias's PPA, I see this: (vivid-ppc64el)adconrad@kelsey01:~$ objdump -T /usr/lib/powerpc64le-linux-gnu/libstdc++.so.6.0.20 | grep 17bad_function_call 0014f268 w DO .data.rel.ro 0028 GLIBCXX_3.4.15 _ZTVSt17bad_function_call 000f7ff0 gDF .text 0050 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD0Ev 000f7f80 gDF .text 0020 GLIBCXX_3.4.18 0x60 _ZNKSt17bad_function_call4whatEv 000f7fa0 gDF .text 0044 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD1Ev 0014f250 w DO .data.rel.ro 0018 GLIBCXX_3.4.15 _ZTISt17bad_function_call 000f7fa0 gDF .text 0044 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD2Ev (vivid-ppc64el)adconrad@kelsey01:~$ objdump -T whee/usr/lib/powerpc64le-linux-gnu/libstdc++.so.6.0.21 | grep 17bad_function_call 000e1e70 gDF .text 0050 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD0Ev 000e1e20 gDF .text 0044 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD2Ev 000e1e00 gDF .text 0020 GLIBCXX_3.4.18 0x60 _ZNKSt17bad_function_call4whatEv 001ea988 w DO .data.rel.ro 0028 GLIBCXX_3.4.15 _ZTVSt17bad_function_call 001ea970 w DO .data.rel.ro 0018 GLIBCXX_3.4.15 _ZTISt17bad_function_call 000e1e20 gDF .text 0044 GLIBCXX_3.4.15 0x60 _ZNSt17bad_function_callD1Ev In other words, it all looks fine to me, so I'm not entirely sure where he's seeing the regression.
