[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#217966: lapack: Fails selftests and builds useless libs (it claims)

reassign 217966 g77

Greetings, and thanks for your report!  As you can tell by the tenor
of the warning message I wrote, I agree with your perspective in
general, and would be much happier having the package build simply
fail if any of the self tests fail.  In fact, this is the way the
package was originally constructed, but in consultation with other
developers, and in the interest of getting woody shipped with several
large packages which depend on lapack (lapack is at the base of a
reasonably large dependency tree), this approach was taken instead.  I
also maintain atlas, blas, and maxima, and have taken the more
conservative tester approach there, which appears to have worked well
in conveying a level of confidence about the package by its very
existence.  I've also spent some time in discussions with upstream
trying to get a zero test fail build (which a few other non-Debian
users have occasionally reported), but unfortunately g77 is not yet
quite capable of compiling a zero test failure lapack, but has
improved dramatically in reducing the number and severity of these
failures quite recently.  My conclusion that the issue lies with g77
and not a bug in lapack stems from non-Debian user upstream reported
tester successes, the recent elimination of the large majority of the
failures by a g77 upgrade, and the fact that, I think with one
possible exception, no single failure appears in all of the Debian
builds on the supported 11 platforms.

It is useful to categorize the failures into two classes, one being a
minor threshold error, where certain tests lose precision in certain
cases.  All current Debian lapack builds have at least some of these
failures, usually just a very few.

There are three platforms with much more serious tester failures,
including failures of the routine to terminate and/or segmentation
faults.  These are at present arm, ia64, and m68k.  You are actually
relatively fortunate in that the m68k build has the fewest number of
such issues among the three.  Indeed, AFAIR, m68k has just recently
been able to compile lapack in sid at all.  

I have in all likelihood overstated the 'useless' case in the message
below -- an argument could well be made that the library could be of
some use to people even with segfaults in a few of its *many*
routines.  If you feel I should reword the message, I'd be happy to
hear a suggestion.  But if we truly want a high quality lapack package
distribution wide, someone is going to have to debug g77 on lapack, at
least on these platforms, and unfortunately I do not have time to do
so myself, at least in the near future.  Upstream will be most
likely of *no* help here, as there are only a very few loosely
connected people who occasionally respond to the reported email
address, and I would be shocked if any of them would have access to
these problem platforms.  Furthermore, lapack is no longer under
current development.  

Perhaps if you care about these issues on the platform of your choice,
you might be able to compile the lib with -g only, run the tester
under gdb, and compare with the result on an i386 box?  If we're
lucky, we may be able to deal with the most egregious cases with an
arch specific lowered optimization setting in the package.

Here are the 'critical' (i.e. non-precision loss only) failures on the
three platforms mentioned above:

 WARNING! 11 tests terminated abnormally!!!
  11 tests with SEGV, files:  ctest.out dec.out dsg.out dsvd.out sec.out ssep.out
  11 tests with SEGV, files:  ssg.out ssvd.out stest.out ztest.out ssvdtim.out
 WARNING! 1 tests had major threshhold errors!
  files:  cnep.out(54/2058)
 15 tests had minor threshhold errors
  files:  cbb.out(4/3000) ced.out(30/5172) cgg.out(2/2184) cgqr.out(1/1728) csep.out(8/11664)
  files:  csg.out(11/10290) csvd.out(12/4840) ded.out(2/3494) dgqr.out(4/1728)
  files:  sgg.out(4/2184) sgqr.out(7/1728) zed.out(24/5172) zgg.out(2/2184) zsg.out(2/10290)
  files:  zsvd.out(4/4840)
 WARNING! 100 tests terminated abnormally!!!
  100 tests with SEGV, files:  cbal.out cbb.out cec.out ced.out cgbak.out cgbal.out
  100 tests with SEGV, files:  cgd.out cgg.out cglm.out cgqr.out cgsv.out clse.out
  100 tests with SEGV, files:  cnep.out csb.out csep.out csg.out csvd.out ctest.out
  100 tests with SEGV, files:  dbal.out dbb.out dec.out ded.out dgbak.out dgbal.out
  100 tests with SEGV, files:  dgd.out dgg.out dglm.out dgqr.out dgsv.out dlse.out
  100 tests with SEGV, files:  dnep.out dsb.out dsep.out dsg.out dsvd.out dtest.out
  100 tests with SEGV, files:  sbal.out sbb.out sec.out sed.out sgbak.out sgbal.out
  100 tests with SEGV, files:  sgd.out sgg.out sglm.out sgqr.out sgsv.out slse.out
  100 tests with SEGV, files:  snep.out ssb.out ssep.out ssg.out ssvd.out stest.out
  100 tests with SEGV, files:  zbal.out zbb.out zec.out zed.out zgbak.out zgbal.out
  100 tests with SEGV, files:  zgd.out zgg.out zglm.out zgqr.out zgsv.out zlse.out
  100 tests with SEGV, files:  znep.out zsb.out zsep.out zsg.out zsvd.out ztest.out
  100 tests with SEGV, files:  cband.out cgeptim.out cneptim.out cseptim.out
  100 tests with SEGV, files:  csvdtim.out ctime.out ctime2.out dband.out dgeptim.out
  100 tests with SEGV, files:  dneptim.out dseptim.out dsvdtim.out dtime.out
  100 tests with SEGV, files:  dtime2.out sband.out sgeptim.out sneptim.out sseptim.out
  100 tests with SEGV, files:  ssvdtim.out stime.out stime2.out zband.out zgeptim.out
  100 tests with SEGV, files:  zneptim.out zseptim.out zsvdtim.out ztime.out
  100 tests with SEGV, files:  ztime2.out
 WARNING! 2 tests terminated abnormally!!!
  2 tests with SEGV, files:  csep.out ssep.out
 WARNING! 7 tests failed to terminate!!!
  files:  csvd.out ctest.out dsvd.out dtest.out zsvd.out ztest.out ztime.out
 5 tests had minor threshhold errors
  files:  cgg.out(1/1273) cnep.out(5/2058) ded.out(1/3502) dnep.out(1/1764) sed.out(25/3508)

Take care,

Goswin Brederlow <brederlo@informatik.uni-tuebingen.de> writes:

> Package: lapack
> Version: unavailable; reported 2003-10-28
> Severity: grave
> Justification: renders package unusable
> Hi,
> when installing lapack I got the following message:
> ----------------------------------------------------------------------
> One or more critical lapack library errors were discovered when this
> package was built.  As of the time of this writing, all known such
> errors are due to compiler and/or ld.so errors on the affected
> architectures.  The lapack libraries in this set of packages then,
> while practically useless for serious numerical research, are provided
> here nonetheless to facilitate smooth upgrades of lapack into Debian
> as a whole.
> ----------------------------------------------------------------------
> So by its own claims this package is absolutely unusable. It also
> breaks anything that uses those broken libraries (hence "renders
> package unusable"). It also breaks the buildds by claiming to fullfill
> the Build-Depends of other packages. This means that packages will be
> build against non functional libraries or hopefully fail to build.
> Thats a big waste of resources.
> There are better ways to get your package into testing without
> creating useless packages.
> MfG
> 	Goswin
> -- System Information:
> Debian Release: testing/unstable
> Architecture: m68k
> Kernel: Linux a4000 2.2.10 #1 Mon Nov 27 20:50:14 CET 2000 m68k GNU/Linux
> Locale: LANG=C, LC_CTYPE=de_DE

Camm Maguire			     			camm@enhanced.com
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Reply to: