dynamic library creation when installing with Cmake - c++

Question

I've been trying to install a package called DAKOTA, which employs BOOST and Trilinos libraries which I'm already using in another program. For compiling and linking I'm using cmake, but I have not been able to pass the make step. It would be very helpful perhaps if you could point me out into some direction. Please find below the cmake command script I'm using to compile and link the libraries, and the process when it stops...
As far as I have understood is the following. I'm using Boost and Trilinos library files used to build the other program to built the project DAKOTA. But I get an error when creating the library file liboptpp.so from Teuchos_BLAS.cpp.o, because it-s being used by libteuchosnumerics.a. I'm not sure if I'm understanding it correctly, but what I got from this is that I need to create a shared library and recompile the Teuchos_BLAS.cpp.o again using -fPIC.
I tried including -fPIC in CMAKE_CXX_FLAGS as you may see below, and also -shared in CMAKE_SHARED_LINKER_FLAGS but this doesn't seem to work. In the past I also tried adding -fPIC in all flags from the CMakeCache.txt but also did not work.
Please let me know your understanding and suggestions.
Thank you very much in advance,
CMAKE COMMAND
! /bin/bash
cmake \
-D CMAKE_INSTALL_PREFIX=/home/pablo/BuildDakota/build \
-D MPI_BASE_DIR:PATH="/usr/lib/openmpi/" \
-D CMAKE_CXX_FLAGS:STRING="-O0 -std=c++11 -pedantic -ftrapv -Wall -fPIC -Wno-long-long" \
-D BOOST_ROOT:PATH=/home/pablo/BuildPeridigm/ \
-D Boost_NO_BOOST_CMAKE:BOOL=TRUE \
-D Boost_NO_SYSTEM_PATHS:BOOL=TRUE \
-D Trilinos_DIR:PATH=/home/pablo/BuildPeridigm/lib/cmake/Trilinos/ \
-D CMAKE_SHARED_LINKER_FLAGS:STRING="-shared" \
/home/pablo/BuildDakota/dakota-6.7.0.src
PROCESS
[ 9%] Building C object packages/external/OPTPP/src/CMakeFiles/optpp.dir/PDS/sort.c.o
[ 9%] Building C object packages/external/OPTPP/src/CMakeFiles/optpp.dir/PDS/writes.c.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/BoolVector.C.o
[ 10%] Building C object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/file_cutils.c.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/ioformat.C.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/mcholesky.C.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/OptppExceptions.C.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/OptppFatalError.C.o
[ 10%] Building CXX object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/print.C.o
[ 10%] Building C object packages/external/OPTPP/src/CMakeFiles/optpp.dir/Utils/timers.c.o
[ 10%] Linking CXX shared library ../lib/liboptpp.so
/usr/bin/ld: /home/pablo/BuildPeridigm/lib/libteuchosnumerics.a(Teuchos_BLAS.cpp.o): relocation R_X86_64_32S against `_ZN7Teuchos11ETranspCharE' can not be used when making a shared object; recompile with -fPIC
/home/pablo/BuildPeridigm/lib/libteuchosnumerics.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
packages/external/OPTPP/src/CMakeFiles/optpp.dir/build.make:2264: recipe for target 'packages/external/OPTPP/lib/liboptpp.so' failed
make[2]: *** [packages/external/OPTPP/lib/liboptpp.so] Error 1
CMakeFiles/Makefile2:1409: recipe for target 'packages/external/OPTPP/src/CMakeFiles/optpp.dir/all' failed
make[1]: *** [packages/external/OPTPP/src/CMakeFiles/optpp.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

Answer 1

I tried including -fPIC in CMAKE_CXX_FLAGS as you may see below, and
also -shared in CMAKE_SHARED_LINKER_FLAGS but this doesn't seem to
work.
Don't do this. Adding low-level compiler flags manually is almost always a bad idea in CMake.
The general approach to request a project to build as a dynamic library is to set the BUILD_SHARED_LIBS option of the project:
cmake -DBUILD_SHARED_LIBS=ON [...]
If this doesn't work right away, it usually means that the project was not intended to be built as a dynamic library, in which case there is no easy solution.
Dakota, for instance, claims to support this option properly.
If this doesn't work, you can try playing around with options like CMAKE_POSITION_INDEPENDENT_CODE, but your chances of success will not be very high. You should probably contact the library maintainer for advice in this case.