https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Sergey Fedorov from comment #4) > (In reply to Iain Sandoe from comment #2) > > it's always been broken, unfortunately (for a start, it gets the range > > wrong) > > At that stage, there were not many exes that were large enough to trigger an > > issue.. > > ... there are various hacks that fix the range - but still that is not > > enough for exes if of significant size - like clang .... > > > > I have a fixed version of ld64 where the branch islands work properly. > > @sergey > > ld64-85.2.1 is borked > > ld64-97.x is better but still limited > > IFF my current published patched ld64 does not work for you - then I will > > have to make some effort to publish the latest. > > I just wanna have the current release of gcc working on ppc64. (I do not see > any point in 10.5 on ppc, since despite some claims which we heard, 10.6 is > just better. However, 10.6 does not have ppc64 support.) > I did have gcc11 building and working on 10.5 ppc64 2–3 years ago, but even > if I can get it working again, that will be a huge step back, and > undesirable mismatch in the toolchain. > > I am fairly sure I tried at least some of your Darwin-xtools releases in a > hope that gonna solve the problem, but to no avail. What I am not sure, > however, is whether I tried to build xtools as 32-bit execs and using those > for 64-bit gcc. > > What is the advisable procedure? I do not really care if gcc itself is 32- > or 64-bit, as long as it can produce 64-bit objects. Same goes for cctools > and the linker. (It is a bit non-trivial to set up in MacPorts, since > everything assumes consistent build_arch, however since I am not constrained > by opinions of its upstream anymore, I can make it work in my fork.) > > AFAIU, there is a choice of a) whether to build a proper 64-bit gcc or b) > gcc pretending to be 64-bit, but capable of compiling for ppc64 (this is how > MacPorts did it with gcc7, it was never genuine 64-bit). And the same for > cctools and ld64, though with some effort these can be built as FAT > executables too. One nuance is that any LLVM that does not require C++11 > cannot be built for ppc64, but it is possible to build llvm5 or llvm7 and > use those. But I tried that with your llvm7, and for ppc64 it still failed. > (On ppc it works nicely.) > Which is more likely to work, given constraints we have? Lets take this discussion elsewhere - e.g. to my Darwin toolchains - there is no upstream solution to this on any of the components (cctools, ld64, gcc, llvm).
