On Thu, Oct 01, 2009 at 11:32:59AM +0200, Kevin Kofler wrote: > Tom Lane wrote: > > > [ ppc64 horror story snipped ] > > > > Well, I'm by no means wedded to ppc64; I just want *some* BE > > architecture in the primary set. Maybe a reasonable compromise would be > > to include ppc but not ppc64? That would cover basic BE portability > > issues, if not the occasional BE-and-64-bit bug. And it would halve the > > present workload of the PPC builders, which might help the build time > > issue. > > Well, AFAIK ppc32 also has this "TOC" mess I was complaining about, it just > has room for twice as many entries because pointers are half the size, so in > practice projects trigger the awfully low ppc64 limit first. And many other targets have similar limitations. Even x86-64 has them, just big enough that you rarely notice (you need to go over 2GB of code/data to start having issues there, and even then there are code models that allow larger code). In some cases it is just -fpic vs. -fPIC, but in other cases the limitations are more severe. Most of the limitations are related to the encoding of instructions, what immediates they allow and what addressing modes they support. It is actually very desirable if developers don't think all the world is i386/x86_64, that leads to horribly unportable code and many bugs go unnoticed. In the OpenBabel case just using an array, or changing the generator to spit more smaller sources, etc. would be desirable for portability. So I think making PPC a secondary arch is a very bad idea and will hurt Fedora quality. Jakub -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
