failure to link against blasfeo_dtrsm after upgrade to Ubuntu 18.04.

[markusgft]

Dear @giaf I recently upgraded one of my computers from Ubuntu 16.04 to Ubuntu 18.04, after which got an unexpected linking error against blasfeo (from hpipm).

/usr/local/lib/libhpipm.a(d_ocp_qp_ipm.c.o): In function `d_ocp_qp_ipm_get_ric_K':
d_ocp_qp_ipm.c:(.text+0x25d2): undefined reference to `blasfeo_dtrsm'
collect2: error: ld returned 1 exit status

It seems related to the feedback matrix getters that you implemented recently. I went back to an ubuntu 16.04 machine with exactly the same code, and can confirm that it still works there. Would you have any pointers for me where to start debugging this?

[giaf]

Hi, that routine is in the BLAS_API of BLASFEO, so you need to make sure that the corresponding make/cmake flag is activated. I don't think it has anything to do with the Ubuntu version.

[markusgft]

Thanks @giaf, I can confirm that I set the flag config as follows when building and installing blasfeo/hpipm.

set(BLAS_API ON CACHE BOOL "Compile BLAS API")
set(FORTRAN_BLAS_API OFF CACHE BOOL "Standard fortran BLAS API") 

which also happens to be the default in the CMakeLists.txt, and which I typically do not modify. But this configuration is what you wanted to make sure, right? Unfortunately, I still cannot find and link against blasfeo_dtrsm. Any further ideas would be highly appreciated.

[giaf]

With the current master in BLASFEO and HPIPM, I am not able to reproduce the issue, for both make and cmake, on Ubuntu 16.04. I can only reproduce the exact same issue if I manually disable the BLAS API.

I will try to get also Ubuntu 18.04 and try there, but it may take a bit of time to do so.

[markusgft]

Hi @giaf, I was able to put a bit more time into isolating the issue, and found the following, which might be worth discussing. The linking problem only occurs after a specific way of installing blasfeo/hpipm.

If I get it correctly, multiple ways of installing the blasfeo/hpipm libraries are supported. Option 1: When I install them as follows

git clone https://github.com/giaf/blasfeo.git
cd blasfeo
make static_library
sudo make install_static
cd ..
git clone https://github.com/giaf/hpipm.git
cd hpipm
make static_library
sudo make install_static

everything works as expected, and cmake finds hpipm/blasfeo in /opt after adding it to the library path.

Option 2: When I instead use

git clone https://github.com/giaf/blasfeo.git
cd blasfeo && mkdir build && cd build
cmake ..
make
sudo make install
cd ../..
git clone https://github.com/giaf/hpipm.git
cd hpipm && mkdir build && cd build
cmake ..
make
sudo make install

the libraries, the package configuration files, etc. are going to be installed in usr/local/<...> and so on. Still, cmake is able to discover the related config *.cmake files, and the include directories seem to be correct. But now I get the originally described linker problems w.r.t. blasfeo_dtrsm. I can replicate the issue for for Ubuntu 18.04 and Linux Mint 19.3 (tested on multiple machines).

Might there be an issue with the standard install target? Is the second way of installation discouraged?

[giaf]

Yes there are two build systems, one based on make and one based on cmake. Personally, I am much more proficient in make and I use it as the default build system myself. On the contrary, cmake is less transparent in itself, and on top of that the cmake build systems in BLASFEO and HPIPM have been build with the contribution of many people, so I am less sure of what is exactly going on there.

That said, first of all by default cmake should install stuff in /opt/... and not usr/local/..., see here https://github.com/giaf/blasfeo/blob/master/CMakeLists.txt#L39 https://github.com/giaf/hpipm/blob/master/CMakeLists.txt#L39 So my fear is that cmake might find another (older ?) BLASFEO build/installation on your machines (maybe from acados? or casadi? or another project ?), which has been compiled without the BLAS_API enabled.

[markusgft]

Okay, that was the decisive hint, I finally was able to figure out what was going on. I now realized tat you recently fixed the prefix path for installation using cmake -- and the version I was using in my testing pipeline dated back a few commits before that day. I still cannot explain the fact to me why Ubuntu 16.04 did not have a problem with the issue, while it faulted on later releases. I now forwarded my testing pipeline to a later set of commits in blasfeo/hpipm and now it works flawlessly. So, it was clearly my bad -- thanks for investing time to help me out! Cheers!

[giaf]

Glad that all is resolved now.

Yes in my opinion cmake is a bit obscure, and only recently I realized that it was ignoring my installation path until I moved it before the project declaration...