Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 505904 - dev-lang/R-3.0.3 does not respect BLAS lib flags
Summary: dev-lang/R-3.0.3 does not respect BLAS lib flags
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Denis Dupeyron (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-26 20:51 UTC by Robert McGehee
Modified: 2014-04-08 17:10 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert McGehee 2014-03-26 20:51:34 UTC
I upgraded from R 3.0.1-r1 to R 3.0.3 and noticed a substantial deterioration in performance in matrix math operations, consistent with a bad or missing BLAS (Basic Linear Algebra Subprogram) library. However, since I use the threaded ATLAS BLAS from the science overlay, _and_ because the R 3.0.3 configuration script indicated that ATLAS blas was used, I did not immediately see the problem.

However, upon further benchmarking I found that R 3.0.3 speeds were identically slow depending on whether I chose the the single threaded or multithreaded version of ATLAS BLAS. Since the multithreaded version should be substantially faster on my 64-core server, this indicated to me that the R 3.0.3 ebuild was not properly linking against the BLAS library specified in 'eselect blas'.

... And true enough, the ebuild script shows the problem beginning with R3.0.2:
Here is the relevant line:

R-3.0.1-r1.ebuild:  --with-blas="$($(tc-getPKG_CONFIG) --libs blas)" \
R-3.0.2.ebuild:	    --with-blas="$($(tc-getPKG_CONFIG) --variable=libdir blas)" \

In R 3.0.1-r1, the correct flags are used from 'pkg-config --libs blas', which in the threaded case is "-lptf77blas" and is "-lf77blas" in the single thread case. However, in R 3.0.2 and 3.0.3, the important "--libs" argument is omitted and only the (uninteresting) libdir variable is called from pkg-config. Since both libraries have the same libdir ($EPREFIX/usr/lib), this argument does not provide enough information to choose a BLAS library, and so R chooses the single threaded one (-lf77blas) and ignores my selection for the threaded version (-lptf77blas).

The solution is revert the offending line in the ebuild.
Comment 1 Sébastien Fabbro (RETIRED) gentoo-dev 2014-03-28 18:41:23 UTC
(In reply to Robert McGehee from comment #0)

> Here is the relevant line:
> 
> R-3.0.1-r1.ebuild:  --with-blas="$($(tc-getPKG_CONFIG) --libs blas)" \
> R-3.0.2.ebuild:	    --with-blas="$($(tc-getPKG_CONFIG) --variable=libdir
> blas)" \
> 

@herobxd: you did the change to the blas system check to solve bug #499356. could you confirm it is needed? pkg --libs blas wfm on my prefix box, and checking quickly the blas autoconf macro in ${S}/m4/R.m4 shows me it accepts more than just the libdir.
Comment 2 Benda Xu gentoo-dev 2014-04-07 11:59:06 UTC
Sorry Robert, it was I who missunderstood the purpose of this option and introduced this regression. Change reverted. Sorry again for the trouble.

Thanks Sébastien.
Comment 3 Robert McGehee 2014-04-08 16:54:57 UTC
Thanks, I tried out the revision and it works as it should. 
Best, Robert