When the compiler just can't cut it....
Greetings! I'm maintaining blas, lapack, atlas, and gcl, and think I
deserve some award or something for maintaining some of the most
unwieldy, marginally portable code out there :-)!
But seriously, I know that every effort should be made to ensure that
all packages will compile properly on all *eleven* (gasp .. how did
this get so high?!) supported architectures, and indeed, it appears
that many of these packages can be made to fit this bill on most
machines.
But on some machines, the compilers simply cannot handle extremely
complex code like this. gcc can't handle atlas-required large branches
on mips, g77 produced lapack is garbage on ia64 (i.e. gives correct
testing answers no where), hppa compilers die on many of these files
and have floating point errors, etc.
What I'm asking is what one is ideally supposed to do in a situation
like this.
1) How far should one push compilation efforts before determining
that a package just won't build on a particular machine?
2) If a package has integrity tests which the build fails in a
serious way, is it better to ship a buggy lib or pronounce the
package un-buildable on said machine?
3) And how does one prevent such a situation from generating
release critical bugs on the package threatening to remove it
from the arches on which it *does* compile perfectly? I.e.,
does the maintainer have the discretion to fill in the
Architecture: field as she sees fit, excluding the problem
cases and essentially giving up on them? I've noticed that
the autobuilders will try to build everything regardless of
Architecture: field.
4) And what if there are several binary packages, some
arch-independent? To my knowledge, there is no Architecture:
field in the Source section.
Please cc me directly with any advise, which is much appreciated in
advance!
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: