2009/10/1 Kevin Kofler kevin.kofler@chello.at:
Jeff Garzik wrote:
Was ppc really such a burden?
Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages.
In fact, my "favorite" ppc64 issue was a problem with OpenBabel hitting a limitation in the ppc64 toolchain: there's a "table of contents" which can grow only to a small fixed size, so large compilation units just don't compile on ppc64, while being perfectly valid C/C++ and compiling fine on all other architectures. (And that's already with the "minimal TOC". Without it, the limit is for the whole executable!) OpenBabel's SWIG-generated bindings exceeded that limit. We were the only ones hitting it as no other distribution is insane enough to build their packages for ppc64. (The binaries don't even get actually used as ppc32 is the preferred multilib on 64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce the amount of TOC entries, which worked for 2 beta releases (requiring additional tweaking for the second one), but then it overflowed again. This was a big annoyance because the new OpenBabel betas were required for new kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream removed some things from their bindings to get them to build, a quite suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs to be redesigned from scratch.
Kevin Kofler
Nice bug; this one is my favourite: https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds don't expand %{_libdir} to the correct place.
You absolutely *cannot* build Eclipse plugins on ppc64 hosts because of this beauty. The current workaround is to just keep resubmitting the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do with Eclipse either, BTW, seems like an RPM or mock problem.)