Include in Catkin Library ROS

[bostoncleek]

Hi,

I am including qpOASES in a catkin library and receive the error described bellow.

My current environment:

• Ubunutu 20.04
• qpOASES release 3.2.1
• gcc 9.3.0

I built qpOASES by running in a build directory:

cmake .. 
make
sudo make install 

When I build my catkin project (running catkin build) I get the following error:

/usr/bin/ld: /usr/local/lib/libqpOASES.a(QProblemB.cpp.o): relocation R_X86_64_PC32 against symbol `_ZNK7qpOASES9QProblemB5getNZEv' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/quadruped_controller.dir/build.make:139: /home/boston/quadruped_ws/devel/.private/quadruped_controller/lib/libquadruped_controller.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:715: CMakeFiles/quadruped_controller.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

When I re-build qpOASES with the following the error above is resolved:

cmake .. -D CMAKE_CXX_FLAGS="-fPIC"
make
sudo make install

Which raises a few questions?

1. I have BLAS and LAPACK installed and would like to link against them. Do I need to modify the CMakeLists.txt that ships with qpOASES?
2. If building with cmake does not invoke the make_linux.mk file where can I find instruction for building with make. When I run make inside the qpOASES directory the build fails because it fails to create /bin/qpOASES.a.

Thank you for your time.

[traversaro]

Hi @bostoncleek, fyi I have two related PRs for enabling shared builds and for permitting to build against system BLAS/LAPACK

• Permit to compile qpOASES as a shared library in CMake #109
• Expose CMake option to avoid Lapack/Blas conflicts #108

At the moment the upstream maintainers of qpOASES probably still need to provide feedback, but I hope this can be useful for you.

[bostoncleek]

Hey @traversaro I checkout out #PR109 and #PR108 thank you for adding the option!

I have discovered another problem (which might be realted to issue #60) is that qpOASES is causing Armadillo to segfault. I suspect this may be because of this replacement file LapackBlasReplacement.hpp for BLAS and LAPACK.

However, the combination of both your PRs fixes the segfault and shared library issues.

What do you think about adding the option to link both BLAS and LAPACK in cmake?

[traversaro]

What do you think about adding the option to link both BLAS and LAPACK in cmake?

So to have an option to link system BLAS and LAPACK and do not include https://github.com/coin-or/qpOASES/blob/326a6517da899cac9766b17ebdcf328858ec6e90/src/BLASReplacement.cpp and https://github.com/coin-or/qpOASES/blob/master/src/LAPACKReplacement.cpp ? This could make sense, but I guess also some changes in the source code may be necessary for that.

[apotschka]

The REPLACE_LINALG flag in the makefiles (e.g., make_linux.mk, line 46) is usually used for this. If set to 1, the files BLASReplacement.o and LAPACKReplacement.o will not be passed to the linker. Instead the system libblas and liblapack will be added to the linker arguments. (Apparently, a similar mechanism still needs to be added for the CMake compilation option.)

The "replacement" approach was chosen so that qpOASES could run on older embedded hardware that does not ship its own system BLAS and LAPACK libraries.

What makes the whole approach a bit fragile is that Fortran integers of the system libraries might come in different sizes (32bit, 64bit). Admittedly, we are not dealing with this issue systematically right now. The key here are the preprocessor variables __USE_LONG_INTEGERS__ and __USE_LONG_FINTS__. Maybe these should be added to CMakeLists.txt. They must be kept in sync with la_int_t and la_uint_type in include/qpOASES/Types.hpp, lines 161ff, and with the system (or Armadillo) linear algebra libraries.

[bostoncleek]

@apotschka I saw the replacement flag in the make file. I was not able to build using the make file because the current release is missing the bin directory.

[apotschka]

The bin directory should be created by the make process. Try mkdir bin before running make as a quick fix.