CMake -fPIC
paulchicos43 opened this issue · 8 comments
I followed the procedures listed in the readme and on command cmake --build ., it fails to produce librefprop.so. The error is:
[ 93%] Linking Fortran shared library librefprop.so
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/libgfortran.a(pause.o): relocation R_X86_64_PC32 against symbol `stdin@@GLIBC_2.2.5' 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
CMakeFiles/refprop.dir/build.make:432: recipe for target 'librefprop.so' failed
make[2]: *** [librefprop.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/refprop.dir/all' failed
make[1]: *** [CMakeFiles/refprop.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I'm trying to find where to put -fPIC. Does anyone know how to solve this problem?
There is a CMake flag for it, but I am surprised I hadn't already enabled -fPIC.
Yes, -fPIC should be enabled for shared libraries: https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html . Can you please show complete build log? Something funny is going on.
librefprop.so successfully compiled eventually, I was missing a dependency. This might sound ridiculous, but is there any way to statically link libgfortran with libm and all librefprop.so dependencies? I'm trying to run librefprop.so as is on a system that I can't install things like fortran on.
To add to this, I've written a c++ wrapper that uses the library and spits out a bunch of properties. It compiles into a single executable that runs with librefprop.so.
librefprop.so successfully compiled eventually, I was missing a dependency. This might sound ridiculous, but is there any way to statically link libgfortran with libm and all librefprop.so dependencies? I'm trying to run librefprop.so as is on a system that I can't install things like fortran on.
Yes (in theory). This is for instance done on OSX, check out the CMakeLists.txt. But getting system libraries to match is a hair-tearing exercise sometimes. You have to make 100% sure you have the same architecture, and possibly the same ABI of things like string library, for instance. So yes, but not for the faint-hearted.
To add to this, I've written a c++ wrapper that uses the library and spits out a bunch of properties. It compiles into a single executable that runs with librefprop.so.
Cool, I've done a lot of that sort of thing too. Is your code somewhere on github/gitlab?
https://github.com/paulchicos43/REFPROP/blob/main/main.cpp
I took some base files from https://github.com/usnistgov/REFPROP-wrappers/tree/master/wrappers/C_CPP that I think you wrote and edited the main.cpp file to do what I want it to.
I'm updating the calculator at irc.wisc.edu/properties to use REFPROP 10 instead of REFPROP 7 which it uses right now.
In C++, your best bet for calling REFPROP (and doing other useful things) is CoolProp: http://www.coolprop.org/.
P.S. You need a different license for REFPROP to make calculations of REFPROP available to the world.