Skip to content

--enable-BLAS-shlib conflict with --with-lapack in configure?

7 messages · Bjørn-Helge Mevik, Brian Ripley, Peter Dalgaard +1 more

Original
Bjørn-Helge Mevik
# 
Dear developeRs,

I'm trying to build R (2.7.1, on an x86_64 running Linux, but I believe
I have observed this on x86 and with earlier versions of R as well)
using external BLAS and LAPACK libraries _and_ generating libR.so,
libRblas.so and libRlapack.so.

Without --enable-BLAS-shlib, configure is able to find and use the
external LAPACK library:

./configure \
  --with-blas="-L/site/intel/cmkl/8.1/lib/em64t -lmkl -lvml -lguide -lpthread" \
  --with-lapack="-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl" \
  --enable-R-shlib
[...]
  External libraries:        readline, BLAS(generic), LAPACK(generic)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           shared R library, R profiling, Java

However, if I add --enable-BLAS-shlib, the external LAPACK will not be
used:

./configure \
  --with-blas="-L/site/intel/cmkl/8.1/lib/em64t -lmkl -lvml -lguide -lpthread" \
  --with-lapack="-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl" \
  --enable-R-shlib --enable-BLAS-shlib
[...]
checking for zgeev_ in -L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl... no
checking for zgeev_ in -llapack... no
[...]
  External libraries:        readline, BLAS(generic)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           shared R library, shared BLAS, R profiling, Java
testing for LAPACK -- but that has not been built yet:

configure:37825: checking for zgeev_
configure:37889: gcc -std=gnu99 -o conftest -g -O2 -fpic  -I/usr/local/include  -L/usr/local/lib64 conftest.c 
-L$(R_HOME)/lib$(R_ARCH) -lRblas  -lg2c -lm -ldl -lm  >&5
/usr/bin/ld: cannot find -lRblas
[...]
configure:37924: checking for zgeev_ in -L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl
configure:37962: gcc -std=gnu99 -o conftest -g -O2 -fpic  -I/usr/local/include  -L/usr/local/lib64 conftest.c 
-L/site/intel/cmkl/8.1/lib/em64t -lmkl_lapack64 -lmkl -L$(R_HOME)/lib$(R_ARCH) -lRblas  -lg2c -lm -ldl -lm  >&
5
/usr/bin/ld: cannot find -lRblas
[...]
configure:37993: checking for zgeev_ in -llapack
configure:38036: gcc -std=gnu99 -o conftest -g -O2 -fpic  -I/usr/local/include  -L/usr/local/lib64 conftest.c 
-llapack  -L$(R_HOME)/lib$(R_ARCH) -lRblas  -lg2c -lm -ldl -lm  >&5
/usr/bin/ld: cannot find -lRblas

(Removing the --enable-R-shlib does not make a difference in this
respect.)

Is this intentional or a bug?  Am I doing something wrong here?
Brian Ripley
# 
This is intentional.  Please note what the R-admin manual says about
--with-lapack, including 'definitely *not* recommended'

If you are concerned about performance you definitely do not want to use 
shared R, not a shared BLAS.
On Thu, 3 Jul 2008, Bj?rn-Helge Mevik wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Bjørn-Helge Mevik
    

    

      
      #
    

  


  

      
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

            

      
      
      
    

        
Ok.

            

      
      
      
    

        
Oh.  I have always understood that as referring to --with-lapack, not
--with-lapack="-L/something...".

            

      
      
      
    

        
I'm sorry, I don't quite follow you here.  Do you mean not create a shared R
and not create a shared BLAS, or was there a "not" too many?

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 3 Jul 2008, Bj?rn-Helge Mevik wrote:

        

            

      
      
      
    

        
It applies to both.

            

      
      
      
    

        
Yes, create neither.  Using shared objects has a noticeable performance 
overhead.

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Bj?rn-Helge Mevik wrote:

            

      
      
      
    

        
"Nor", I think. (One of a set of confusing typos. Others include "not"
instead of "now" or "note". Note that I would ever make such silly
mistakes.)

As for the subject matter, you _can_ actually create such at thing as an
optimized, shared BLAS/Lapack, and it is probably faster than an
unoptimized, shared one (well, at least you could create them when I
played with this some years ago). It's just that people think it is a
bit silly, so they are not doing it for you, and as I recall it, you
also need to tinker a bit more than usual with the build process of the
libraries.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 3 July 2008 at 14:08, Peter Dalgaard wrote:

        
| As for the subject matter, you _can_ actually create such at thing as an
| optimized, shared BLAS/Lapack, and it is probably faster than an
| unoptimized, shared one (well, at least you could create them when I
| played with this some years ago). It's just that people think it is a
| bit silly, so they are not doing it for you, and as I recall it, you

Debian has provided optimised Atlas libraries, compiled as shared libraries,
for over eight years. So not everybody sees this as 'silly'. We set up our R
builds to transparently use them.  That way you'd get tuned linear algebra as
a plug-in -- and the plugin is made possible because of the shared-library
build.

So not everybody agrees with BDR's resolute statement implying static-only
builds if one is concerned about performance.  Performance is almost always
relative, and often relative to several possibly conflicting baselines.

Dirk