[mlpack-git] [mlpack] libmlpack.so.2.0: undefined reference to `wrapper_dgesv_' (#499)

[Ryan Curtin]

Hand-compilation with no internet... that sounds quite frustrating. :(

I think that what's happening here is that the configuration file for Armadillo (which will be /home/test/local_cxx11/include/armadillo_bits/config.hpp ) is not being used correctly.  I see you've modified CMakeLists.txt to automatically set `ARMADILLO_INCLUDE_DIR`, `ARMADILLO_INCLUDE_DIRS`, `ARMADILLO_LIBRARY`, and so forth, instead of calling `find_package(Armadillo 4.100.0 REQUIRED)`.  But this is potentially a bad idea because the `FindArmadillo.cmake` script is actually pretty complex and has to parse `config.hpp` to determine how Armadillo should be linked against.

More specifically, the value `ARMA_USE_WRAPPER` in `config.hpp` controls whether or not `libarmadillo.so` should be linked against, or if linking against LAPACK/BLAS/ARPACK/etc. is required.  I think the value of that variable also controls whether or not libarmadillo.so is built with any symbols in it at all.

So I think a first step here might be to remove the manual setting of Armadillo variables in CMakeLists.txt, and revert to the original find_package() call.  You should be able to specify the Armadillo directories on the command line to cmake like this:

```
$ cmake -D ARMADILLO_INCLUDE_DIR=/home/test/local_cxx11/include -D ARMADILLO_LIBRARY=/home/test/local_cxx11/lib/libarmadillo.so ..
```

plus any other options for your compiler or any other CMake options.  That may potentially fix the issue since the CMake script is supposed to parse the Armadillo configuration and link properly.

If not, there are a couple more possibilities:

 * We should check and verify that `libarmadillo.so` actually has the `wrapper_` symbols in them; I generally do this with `strings libarmadillo.so | grep wrapper` and make sure that the output is not empty.
 * We should ensure that `libarmadillo.so` is properly linked to LAPACK/BLAS/etc., which I'd check with `ldd libarmadillo.so` (if you can provide the output of that, it could be very helpful).
 * A verbose make log will reveal exactly what the linker is trying to link against.  I should have asked for this last time, but I forgot the verbose flag... `VERBOSE=1 make` (it'll probably be pretty long).

---
Reply to this email directly or view it on GitHub:
https://github.com/mlpack/mlpack/issues/499#issuecomment-171657755
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/mlpack-git/attachments/20160114/07af90a1/attachment.html>