0

Beginner here so apologies if the question is basic or poorly organized.

I am trying to link Armadillo 10.3.0 to OpenBlas 0.3.13 on Windows 10 using the pre-compiled OpenBlas here and am running into undefined reference issues.

When I compile my C++ using g++ my_script.cpp -o my_script -I "C:/.../armadillo-10.3.0/include" -DARMA_DONT_USE_WRAPPER -L "C:/.../armadillo-10.3.0/examples/lib_win64/libopenblas.dll" -I "C:/.../boost_1_75_0", it works perfectly when my_script.cpp only includes basic Arma operations.

However, if I add certain Arma operations (e.g., chol, mvnrnd) I run into several undefined reference to `xxx' issues (see example below) when I try to compile:

C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\XXX\AppData\Local\Temp\12\cc0AVY6p.o:my_script.cpp:
(.text$_ZN4arma6lapack5syevdIdEEvPcS2_PiPT_S3_S5_S5_S3_S3_S3_S3_[_ZN4arma6lapack5syevdIdEEvPcS2_PiPT_S3_S
5_S5_S3_S3_S3_S3_]+0x83): undefined reference to `dsyevd'

I have tried:

  • Playing around with armadillo_bits/config.hpp to adjust flags per here
  • Checking arma::arma_config to see if .blas and .lapack are true / enabled after compiling the version of my_script.cpp without the troublesome Arma operations (they are true/enabled)

If anyone has any thoughts on this would appreciate any guidance, thanks!

Ðаn
  • 10,934
  • 11
  • 59
  • 95
cap
  • 1
  • There is a difference between the `-L` and `-l` options to gcc (uppercase and lowercase versions of L). `-L` specifies the path (folder). `-l` specifies the library. So try using this: `g++ my_script.cpp -o my_script -O2 -I "C:/.../armadillo-10.3.0/include" -DARMA_DONT_USE_WRAPPER -L "C:/.../armadillo-10.3.0/examples/lib_win64/" -l libopenblas -I "C:/.../boost_1_75_0"`. Also don't forget to enable optimization with `-O2` – hbrerkere Mar 27 '21 at 04:07
  • Ah makes sense, thanks! I updated the g++ to reflect the above and it was able to compile (which is an improvement). New issue is that when I run the compiled executable, it claims to not find ``libopenblas.dll`` even though ``libopenblas.dll`` is stored in the path corresponding to the ``-L`` flag. I can mess around with it as this might be separate though – cap Mar 27 '21 at 21:42
  • Maybe also try liking with `libopenblas.lib` instead of `libopenblas.dll`. The former is probably a stub for loading the latter at runtime. Windows is notorious for having very primitive handling of shared libraries. – hbrerkere Apr 06 '21 at 01:14
  • I tried that but it did not end up working. I just got it to work and the solution was putting ``libopenblas.dll`` in the same directory as my compiled .exe. Thanks for the help on this! – cap Apr 16 '21 at 18:36

0 Answers0