On 13 February 2018 at 22:07, Ralf Stubner <ralf.stub...@r-institute.com> wrote:
> On 13.02.2018 05:49, Baptiste Auguie wrote: > > On 13 February 2018 at 01:05, Dirk Eddelbuettel <e...@debian.org > > <mailto:e...@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.stub...@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]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel