On Sat, Dec 22, 2001 at 01:49:12PM -0500, Ben Collins wrote: > Of course it is broken. It is _not_ supported on sparc, other than to > make it available to users. _I_ do not want anything built on sparc that > doesn't use the default compiler (except in cases such as libc6-sparc64 > where we obviously have to use the 64-bit capable gcc-3.0 compiler). > > It should be policy that programs are required to use the default > compiler on an arch. You create serious overhead on arch maintainence > when you ignore that.
[Sorry if I'm just being paranoid; I may just be knee-jerking to A Pronouncement From The Debian Project Leader which isn't.] While I don't disagree with such a policy in general, I think that exceptions should be allowed. On ia64, there really isn't a super-strong code generation engine available. The default gcc (2.96!) is a bit behind in bugfixes, and gcc 3.x, although much better at generating ia64 code, has other weaknesses. We try to build everything with gcc 2.96 as much as possible, but in some cases, gcc 3.0 is required to get code that works. In those cases, we haven't seen anything wrong with debian/rules hackery to set CC=gcc-3.0 and so on, and Build-Depend on gcc-3.0 [ia64]. Is this something you object to? I understand how you might object on sparc, since gcc 2.95 has supported sparc for a long time now. But on newer architectures, we may not have the luxury to mandate a single gcc version. And if you object, could you suggest a solution? Some of the packages affected are very large and complex and "fix the problem in the source of your package" would, most likely, involve quite a bit of work. I suspect in a few of those cases that the only feasible response would be to remove the package from the architecture, which seems a shame if building with a different compiler would fix the problem.
