[R-pkg-devel] Lapack: undefined symbol: zgbsv_

[Baptiste Auguie]

On 13 February 2018 at 22:07, Ralf Stubner <ralf.stubner at r-institute.com>
wrote:

> On 13.02.2018 05:49, Baptiste Auguie wrote:
> > On 13 February 2018 at 01:05, Dirk Eddelbuettel <edd at debian.org
> > <mailto:edd at debian.org>> wrote:
> >     Maybe we are setting a more global "no advanced lapack" for Windows
> that
> >     assures success when we assume that the other system will always
> >     have it.
> >
> >
> > it sounds plausible, but it would be nice to know for sure.
>
> It is the case, c.f.
> https://github.com/RcppCore/RcppArmadillo/blob/master/inst/i
> nclude/RcppArmadilloConfig.h#L96-L106
>
> > In
> > particular, it doesn't explain why the external Lapack on linux appears
> > to be missing these symbols (they're not very recent, as far as I can
> > tell). I don't really know how to figure this out, but it seems to be
> key.
>
> My understanding:
>
> * On Windows internal LAPACK is used but it is not affected due to the
> defines quoted above.
> * At least Debian & Co but probably also other Linux distributions
> compile R with external LAPACK and are not affected.
> * CRAN (and probably r-hub) use R compiled with internal LAPACK and is
> therefore affected.
>


Thanks Ralf, now it makes more sense to me. I had misunderstood the
situation on CRAN and r-hub and thought they used an external Lapack on
linux.



> * I do not understand why Mac OS is not affected. The FAQ [1] implies
> that by default the internal BLAS/LAPACK is used. But then I do not see
> the mentioned alternative libRblas.vecLib.dylib on a test system.
>
> [1]
> https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which
> -BLAS-is-used-and-how-can-it-be-changed_003f
>
>
> >     Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.
> See
> >     lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac
> >:
> >     https://github.com/RcppCore/RcppArmadillo/blob/master/confi
> gure.ac#L67-L95
> >
> > while this might solve the CRAN problem, it doesn't feel right to
> > enforce the use of suboptimal routines throughout and on all platforms,
> > including those that do in fact provide a full-fledged external Lapack.
>
> You could use this as a first step to get the package back into CRAN.
> Later on you can try to only set the flag when an internal LAPACK is
> detected, similar to the way RcppArmadillo does it. If my understanding
> above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your
> package but not in RcppArmadillo will be quite small.
>

It would make sense to test for internal vs external Lapack and decide
based on that (regardless of the OS); as you say, the results should be
essentially identical to what happens when the same user installs
RcppArmadillo on their machine. Unfortunately I don't know how to proceed.
I copied RcppArmadillo's configure.ac script and tried to extract just the
Lapack testing bits, but these macro and configure concepts are totally
foreign to me. I believe it would be helpful to have a minimal example of
this type of configuration for the dummy isolve package (
https://github.com/baptiste/isolve), if someone with such expertise and a
linux machine is willing to help.

Thanks,

baptiste


>
> Greetings
> Ralf
>
> --
> Ralf Stubner
> Senior Software Engineer / Trainer
>
> R Institute GmbH
> Dortustraße 48
> 14467 Potsdam
>
> T: +49 331 23 70 81 66
> F: +49 331 23 70 81 67
> M: +49 162 20 91 196
>
> Mail: ralf.stubner at r-institute.com
>
> Sitz: Potsdam
> Register: AG Potsdam HRB 27966 P
> Ust.-IdNr.: DE300072622
> Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze
>
>

	[[alternative HTML version deleted]]