Hi all! I am trying to install preCICE on a cluster system. The cluster uses the module system to help users load and unload modules. I followed the preCICE wiki and also the instructions on the page for installing preCICE on the CooLMUC2 (LRZ Linux cluster).
I tried two strategies:
If I run module load boost I get a system loaded boost 1.66 compiled with intel 18 compilers
Manually installing Boost 1.72.0 in a folder and providing the library and include paths
For both the strategies I see the following error:
/usr/bin/ld: CMakeFiles/testprecice.dir/src/testing/main.cpp.o: in function `init_unit_test()':
/u/idesai/precice/src/testing/main.cpp:60: undefined reference to `boost::unit_test::runtime_config::btrt_log_level[abi:cxx11]'
/usr/bin/ld: CMakeFiles/testprecice.dir/src/acceleration/test/AccelerationMasterSlaveTest.cpp.o: in function `boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)':
/u/idesai/boost_install/include/boost/test/tree/test_unit.hpp:265: undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name[abi:cxx11](boost::unit_test::basic_cstring<char const>)'
/usr/bin/ld: libprecice.so.2.0.1: undefined reference to `boost::log::v2_mt_posix::aux::code_convert_impl(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, std::locale const&)'
/usr/bin/ld: libprecice.so.2.0.1: undefined reference to `boost::log::v2_mt_posix::parse_error::throw_(char const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::log::v2_mt_posix::attribute_name const&)'
collect2: error: ld returned 1 exit status
CMakeFiles/testprecice.dir/build.make:1049: recipe for target 'testprecice' failed
make[2]: *** [testprecice] Error 1
CMakeFiles/Makefile2:141: recipe for target 'CMakeFiles/testprecice.dir/all' failed
make[1]: *** [CMakeFiles/testprecice.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
I think it is also relevant to mention that I had problems earlier when I used the icpc compiler in the Intel 18 compiler set as the CXX_COMPILER in the CMake installation of preCICE. CMake said that the compiler is not C++11 compliant for N2071 and N2072 operations which are related to time manipulation. I got around this by using GCC 9.2.0 for the compilation.
Yes, I remove the build folder completely every time I try to build preCICE. I unloaded the boost module and ensured that it is not loaded by checking module list.
I went through the documentation of Find_BOOST package in CMake to check if there is a heirarchy of variables and paths that CMake checks first, and the documentation says CMake looks for BOOST_ROOT path. Interestingly the IPP people had encountered this same issue at the preCICE Workshop and were unable to solve it.
Note that BOOST_ROOT can be both a CMake variable and an ENV.
Thus you could try to adding -DBOOST_ROOT=... to cmake when you configure precice.
The documentation of FindBoost contains more details.
Also the problem with some compilers is that they do not ship with a standard library anymore.
The intel compiler detects the GCC standards library at runtime. Thus you have to additionally load at least GCC 5 in order to use it with preCICE.
Hi @fsimonis,
The -DBOOST_ROOT=... was not identified directly by CMake but I got the clue and finally this command made sure CMake saw the correct Boost installation:
Hi @ajaust,
I downloaded Boost from the website and installed it by the following steps:
tar -xzvf boost_1_72_0.tar.gz
cd boost_1_72_0
./bootstrap.sh --with-libraries=log,thread,system,filesystem,program_options,test --prefix=/path/to/installation/target
./b2
./b2 install
I do add log and test to the flag --with-libraries and I see them being compiled in the terminal output so I am quite sure they are being compiled.
Would you still recommend a separate installation of Log and Test libraries?
I guess that should be fine the way you did it. Could you attach the full CMakeError.log and CMakeError.log that find in the subdirectory CMakeFiles/ of your preCICE build directory? Maybe this brings some enlightement.
Before rebuilding I would just check if the files of the needed boost libraries are present.
The errors look rather reasonable to me. If I compile preCICE 2.0.1 on my laptop I get similar output.
Did you verify that you have indeed a libbost_log.so and a libboost_unit_test_framework.so?
Could you also check the file CMakeFiles/testprecice.dir/link.txt (from the preCICE build directory) and maybe upload it. This should show what the actual command for linking is. You could also try a verbose build by using make VERBOSE=1 and/or setting the CMAKE_VERBOSE_MAKEFILE variable to ON for additional log files.
What do you think is actually happening now? Is CMake still not able to find the Boost or is there something wrong in my Boost installation?
I confirmed that libboost_log.so and libboost_unit_test_framework.so exist and I am pointing correctly to the folder lib/ which has them.
I checked the link.txt and it does consist of the correct path to the boost .so files. Here is the file: link.txt (6.5 KB)
I will try the build again with VERBOSE.
@ajaust okay you have given me some direction where to look!
I will test build preCICE with the additional option you have suggested.
Also I now suspect Boost is being compiled with another compiler than preCICE. (I am using GCC 9.2.0 for preCICE too, dropped the Intel compilers for now).
I sadly have no experience with the linkers you have mentioned (ld vs. gold), but will look into that too
I have managed to compile preCICE on the cluster I am working on! The problem was that the cluster would load an intel compiler set by default on start and Boost was picking up the Intel compiler even when I had added GCC using module load gcc.
The following steps finally made it work:
Unload the intel compilers with: module unload intel
Load GCC 9.2.0 with: module load gcc
Build Boost manually (ensure that it uses GCC 9.2.0)
Great to hear that it works. I can generally recommend using module purge (unloads all modules) and then explicitly loading the modules one wants to use before compiling software.
I suppose a more convenient way to solve this problem would be to manually specify the toolset when building boost. We should probably add this to our documentation too. I added this to the Boost section of the dependencies page in the wiki.
