From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko) Description of problem: If R is compiled with Fedora Extras lapack, make check fails. This does not happen if R is compiled with the lapack version it ships. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Goto R source code: ./configure --with-lapack make make check Actual Results: make check fails in tests/Examples/base-Ex.Rout.fail Additional info: This bug looks to be related with https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169399
Following the suggestions given in the r-devel list I have traced the lapack package in debian: http://packages.qa.debian.org/l/lapack.html Looking there for any bug related to that reported in R-admin manual a likely candidate is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111374 So although similar this bug does not seems to be the same that plagued debian before.
OK, so this "bug" in lapack is caused by the errata patch from upstream: http://www.netlib.org/lapack/release_notes.html Specifically, one of these changes is described by upstream as: 10/5/2000 Corrected error with LQUERY and setting of WORK(1) This change is what is confusing R. To the best of my knowledge, it looks as if this change now requires all of the parameters to the DGEBRD calls to be valid, as opposed to before where it simply ignored invalid parameters. DGEBRD gave error code -10 (the error that the test throws from lapack) means that the 10th parameter passed to the function (v) is invalid. The pre-patch code seems not to care that some parameters are invalid. However, I'm not sure this is worth fixing for several reasons: 1. I'm disinclined to remove a patch from lapack that has been included since 2001 because an application is passing invalid parameters to it. 2. The Fedora Extras version of R uses the R-bundled mini-lapack, not the Fedora Extras lapack. 3. Upstream direction seems to imply that this patch will be included in a next generation version of lapack. I emailed them to try and get clarification but have not received a response. (See: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=80)
The R upstream authors had a fix for this issue, which I tested and confirmed as a lapack bug. The fix will be in lapack-3.0-33 (FC-4 and devel).