Skip to content

make hanging during compile of r-patched/R-devel on Fedora Core 3

11 messages · Marc Schwartz, Brian Ripley, Peter Dalgaard +1 more

#
Hi,

On a new Dell laptop, with a fresh FC3 installation (with latest updates 
applied) I am experiencing make hanging consistently after/during 
building grDevices. This happens when using the configure flag 
--with-lapack (I have the LAPACK rpm distributed with FC3 installed). 
The last two lines of output are:

make[5]: Leaving directory 
`/home/gavin/R/devel/build/src/library/grDevices/src'
make[4]: Leaving directory 
`/home/gavin/R/devel/build/src/library/grDevices/src'
hang here

There are no errors or warnings printed to the console.

The same thing happens with r-patched. Both source trees were checked 
out using subversion.

If I remove the configure flag for lapack, r-patches and r devel both 
build fine. I'm not sure where to look for error messages or to diagnose 
the problem. Has anyone experienced a similar problem? Where should I 
look for any errors/logs? Any other suggestions?

All the best,

Gavin
#
On Wed, 2005-05-04 at 13:56 +0100, Gavin Simpson wrote:
Gavin,

FWIW, I can duplicate this behavior on my Dell 5150 w/ FC3 using the r-
patched tarball from 2005-05-03.

I thought that perhaps this might be related to the use of the nVidia
proprietary driver, but temporarily going back to the 'nv' driver did
not resolve the problem.

Thus, I am unable to provide more information as to the etiology of the
problem other than to point to some of the references in the r-admin
manual starting on page 19 regarding linear algebra.

Perhaps there is a problem with the FC3 LAPACK.

Best regards,

Marc Schwartz
#
Marc Schwartz wrote:
Cheers for this Mark,

I had a quick google search for this problem and found a discussion in 
the redhat mailing list archives that discusses the issue and points to 
the following bug:

https://bugzilla.redhat.com/beta/show_bug.cgi?id=138447

Which describes the behaviour I am experiencing.

Basically, the LAPACK in FC3 is broken because it was compiled with 
gcc-3.4 and that introduced errors when -O2 optimisations were used to 
compile the rpm. That bug was recently reopened so there may be the 
possibility of the FC3 rpm being updated (the underlying problem has 
been fixed by compiling with lower optimisation).

I'll read more of the r-admin, and see about finding an alternative.

Also, note that lapack has been moved to Fedora Extras from FC4 so 
that's one more thing to remember to add after upgrading!

All the best,

Gav
#
On Wed, 4 May 2005, Marc Schwartz wrote:

            
In any case, we do not recommend an external LAPACK unless it is 
essential.  There are far too many buggy ones about, and there is no 
performance gain in using someone else's compile of a nearly identical 
code base.  Is

   Provision is made for using an external LAPACK library, principally to
   cope with BLAS libraries which contain a copy of LAPACK (such as
   @code{libsunperf} on Solaris and @code{vecLib} on Mac OS X).
   However, the likely performance gains are thought to be small (and may
   be negative), and the default is not to search for a suitable LAPACK
   library.

   If you do use @option{--with-lapack}, be aware of potential problems
   with bugs in the LAPACK 3.0 sources (or in the posted corrections to
   those sources).  ....

not enough warning?
#
On Wed, 2005-05-04 at 16:58 +0100, Gavin Simpson wrote:
<snip>
Thanks for the update Gavin.

For FC4, there are a lot of things that are either going to be new in or
are moving to Extras (including R BTW). Much controversy over some of
the decisions made there, but that's another topic for another thread in
a different galaxy, far, far away...  ;-)

Best regards,

Marc
#
On Wed, 4 May 2005, Gavin Simpson wrote:

            
Yes, that _is_ described in R-admin, and R is itself careful to compile 
the critical routines with -ffloat-store.
#
Gavin Simpson <gavin.simpson@ucl.ac.uk> writes:
There's a pending update on lapack/blas now, which may or may not fix
the issue (no announcement in the archives).

Any clue whether there is any benefit in using the FC3 versions over
the versions that ships with R?
#
On Wed, 2005-05-04 at 21:15 +0200, Peter Dalgaard wrote:
Peter,

I cannot offer an authoritative response here and perhaps Gavin has
other information. 

Recognizing "the absence of evidence is not evidence of absence", I have
not seen anything (benchmarks, etc.) to suggest that there is an
advantage.

Regards,

Marc
#
On Wed, 4 May 2005, Peter Dalgaard wrote:

            
Yes: at least for earlier versions, none. (See the comments in the R-admin 
manual I quoted yesterday which no one else seems to have read.)
#
Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:
I did know about them. I was being mildly sarcastic and partly
curious. 

In principle, having lapack/blas maintained as part of the
distributions would be good, especially if they could sort out the
(nontrivial) processor-specific tuning issues. Currently, the RPMs of
R for both SuSE and Fedora ship with minimal tuning, and you need to
compile your own version to take advantage of (say) an ATLAS blas.
This is not hard to do, but you lose the niceties of the RPM system
with respect to upgrades, dependencies and all that.

In practice, if the distributions also ship minimally tuned libs, and
buggy ones too, the point gets rather moot.
#
Peter Dalgaard wrote:
Just to draw this particular thread to a close - I gave the FC3 lapack a 
run - as I'm stubborn and (like Peter) a little curious. The compilation 
proceeded without hangs, errors or warnings, but make check failed 
whilst running the examples from base. So looks like everything written 
in R Admin document holds for at least the current lapack distributed 
with FC3 (yes, I did read it!), so it looks like relying on 
distributions for lapack is not going to work just yet...

I provide the output from make check and base-Ex.Rout.fail just for 
illustration. I am quite happy with my R and the inbuilt lapack and FC3 
provided blas - I was using the arrival of a new laptop as an excuse to 
try out a few things I had avoided previously and have learnt quite a 
lot in the process.

Thanks for everyone's input.

All the best,

Gav

Output from make check:

....
make[5]: Entering directory `/home/gavin/R/buildLapack/src/library'
  >>> Building/Updating help pages for package 'base'
      Formats: text html latex example
make[5]: Leaving directory `/home/gavin/R/buildLapack/src/library'
running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
make[4]: Leaving directory `/home/gavin/R/buildLapack/tests/Examples'
make[3]: *** [test-Examples-Base] Error 2
make[3]: Leaving directory `/home/gavin/R/buildLapack/tests/Examples'
make[2]: *** [test-Examples] Error 2
make[2]: Leaving directory `/home/gavin/R/buildLapack/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving directory `/home/gavin/R/buildLapack/tests'
make: *** [check-devel] Error 2

And from base-Ex.Rout.fail we have:

....
 > ### Name: kappa
 > ### Title: Estimate the Condition Number
 > ### Aliases: kappa kappa.default kappa.lm kappa.qr kappa.tri
 > ### Keywords: math
 >
 > ### ** Examples
 >
 > kappa(x1 <- cbind(1,1:10))# 15.71
[1] 15.70590
 > kappa(x1, exact = TRUE)        # 13.68
[1] 13.67903
 > kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
[1] 8.351867e+16
 >
 > hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
 > sv9 <- svd(h9 <- hilbert(9))$ d
 > kappa(h9)# pretty high!
[1] 728289254735
 > kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10
Execution halted