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

[Dirk Eddelbuettel]

On 14 February 2018 at 17:12, Baptiste Auguie wrote:
| 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.

This has been unchanged over the many years that you had these battles:

- on Windows it is always internal lapack 
- on Linux it depends and that is why RcppArmadillo checks, and always has 
- on macOS I forget what it is for LAPACK (but it can't be more general that
  Linux) but we absolutely fight the rather poor OpenMP situtation there

so in a nutshell you *must* test.

Which is what RcppArmadillo does in two stages. First, we accomodate Windows
and then in other cases we defer to the result form the test in configure.
This is from RcppArmadilloConfig.h where it gets "used" on all but one platform:


// On Windows do not read autoconf-updated header
#if defined(WIN32) || defined(_WIN32)
  // R can be built with its own Rlapack library, or use an external
  // one. Only the latter has zgesdd, a complex-valued SVD using divide-and-conquer 
  // on Windows we do not assume ZGESDD
  #define ARMA_CRIPPLED_LAPACK 1
  // on Windows we can now assume OpenMP with Rtools / gcc 4.9.3
  // note that performance is said to still be poor
  // cf https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#The-MinGW_002dw64-toolchain
  #define ARMA_USE_OPENMP
#else
  // on the other OSs we test via LAPACK_LIBS (in configure) which
  // updates this include file
  #include <RcppArmadilloConfigGenerated.h>
#endif


Now, as hinted, I just allowed in RcppArmadilloConfigGenerated.h to be blunt
and override the tested value:


#ifndef ARMA_CRIPPLED_LAPACK
// value on next line may be changed between #undef and #define by the configure script
@ARMA_LAPACK@
#endif


So you can now (or from the next release "soon") override from cda, at least
as a test for builds. Otherwise it receives what we test for in autoconf
(which does not cover your newest complex solve issue as it was calibrated
for earlier issues now addressed by R Core who made the include LAPACK
"bigger", though not big enough for your newest issue).

And RcppArmadillo had these tests for many years: as autoconf/configure code,
then as a shell script snippet, and now back to autoconf.  
 
| 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

See above; RcppArmadillo does just that.

| 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.

I can try to help by email, and I think I offered that before.  autoconf
really is just like shell scripting, plus a little ornamentation.  The
configure.ac script should not be hard to read (and copy) and there are
numerous examples on the intertubes.  You are also free to do what others do
and completely reinvent autoconf if that floats your boat better. Your call.

But you really need a test for your situation, or at least fall back to the
very blunt instrument we provide for you.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org