Cmake on centos 7.5
Hello, i have some troubles about cmake step to install corsika 8 on centos 7.5. I saw there was an issue last year and he had same problems. It's very important for me to have a version without docker for my benchmarks (performance counters).
I use gcc/gfortran/g++ version 8.3 + cmake 3.19 (PATH modified).
I did pip command for conan, created folders like readme,... but i have always the same problem when i use cmake (after that, make doesn't work, there are multiple errors) :
On my laptop on ubuntu 20.04, I haven't these problems.
Activity
added Bug label
Yes I have python 3.8.5
Edited by Matthieu Carrere
Ok I found something. When I use cmake 3.12.3, I hadn't warnings and this message anymore :
CORSIKA8 is not created in this directory. For compatibility with older versions of CMake, link libraryBut I have many errors while "make" with spdlog just after that :
[ 79%] Linking CXX executable ../../bin/testFramework
Hi Matthieu. Thanks for reporting this!
cmake 1.19
In fact, I use cmake 1.16.3 now and I get the same output from cmake as you reported in the first place.
However, it is important to note these are all just warnings of the type
CMake Warning (dev) at modules/urqmd/CMakeLists.txt:57 (target_link_libraries): Policy CMP0079 ...and the cmake process finishes successfully
-- Configuring done -- Generating done -- Build files have been written to: /home/mcarrere/corsika-buildIn my case, in this scenario I can successfully build corsika afterwards with "make" etc. So, if "make" fails for you then please also attach the output of "make VERBOSE=1". If make works: ignore the cmake warnings...
cmake 1.12
This should definitly work. Was this a clean install? Did you removed the "CMakeCache.txt" at minimum or best start from an empty build directory?
It might be that the cmake message you report here
CORSIKA8 is not created in this directory. For compatibility with older versions of CMake, link libraryis a sign that you mixed in a build directory different versions of cmake. This won't work.Best: also include cmake log output...
I "rm" all the corsika_build for each try. I modify the path in my bashrc file so cmake is the good version.
My commands in corsika_build : 3.19.0
[mcarrere@daliserv512 corsika-build]$ cmake --version cmake version 3.19.0 CMake suite maintained and supported by Kitware (kitware.com/cmake). [mcarrere@daliserv512 corsika-build]$ cmake ../corsika -DCMAKE_INSTALL_PREFIX=../corsika-install &>cmake_3.19.log [mcarrere@daliserv512 corsika-build]$ make -j16 VERBOSE=1 &>make_3.19.log [mcarrere@daliserv512 corsika-build]$ make install VERBOSE=1 &>make_install_3.19.logI change the directory for cmake, source my bashrc and : 3.12.3
[mcarrere@daliserv512 corsika-build]$ chmod +rwx -R ./*; rm -r ./* [mcarrere@daliserv512 corsika-build]$ cmake --version cmake version 3.12.3 CMake suite maintained and supported by Kitware (kitware.com/cmake). [mcarrere@daliserv512 corsika-build]$ cmake ../corsika -DCMAKE_INSTALL_PREFIX=../corsika-install &>cmake_3.12.log [mcarrere@daliserv512 corsika-build]$ make -j16 VERBOSE=1 &>make_3.12.log [mcarrere@daliserv512 corsika-build]$ make install VERBOSE=1 &>make_install_3.12.logIt's not a mistake of me. Something is not correct. I'm not alone in this case for Centos7.
ps : I took these versions here : https://cmake.org/download/
Edited by Matthieu Carrereadded Build System label
-
There is something happening with the conan-compiled spdlog library at
/home/mcarrere/.conan/data/spdlog/1.8.0/_/_/package/c7e1b1004c948250b7562beecd9031d66e8b92a7/lib/libspdlog.aplease also send the output of
nm /home/mcarrere/.conan/data/spdlog/1.8.0/_/_/package/c7e1b1004c948250b7562beecd9031d66e8b92a7/lib/libspdlog.aAnd another thing that you please try is to either delete or just move away
/home/mcarrere/.conan/data/spdlog/1.8.0/_/_/package/c7e1b1004c948250b7562beecd9031d66e8b92a7and the re-run CORSIKA cmake && make. Please attach the log files again.The cmake version should not matter.
Btw:if you first update your corsika git version the other cmake warnings should not appear any more (CMP00079).
There is something happening with the conan-compiled spdlog library at
/home/mcarrere/.conan/data/spdlog/1.8.0/_/_/package/c7e1b1004c948250b7562beecd9031d66e8b92a7/lib/libspdlog.aplease also send the output of
The output : spdlog.output
And another thing that you please try is to either delete or just move away
/home/mcarrere/.conan/data/spdlog/1.8.0/_/_/package/c7e1b1004c948250b7562beecd9031d66e8b92a7and the re-run CORSIKA cmake && make. Please attach the log files again.Btw:if you first update your corsika git version the other cmake warnings should not appear any more (CMP00079).
It's work without warnings now. It's great.
-
I notice these things:
- the spdlog conan ID has changed and is now: ff8d59d47be9cd9bef245bc941640efed49089de
- did you do anything differently than before? I am surprised that a different version of spdlog is requested by conan this time. @rprechelt any idea?
- the actual error is from pthread.
Please try this next:
- I made a new test branch:
git checkout centos--> it only linkt to pthread in addition. Pleas try. Also please send the output ofmake VERBOSE=1. Thanks!
pthread is fixed now but there is always this problem with spdlog on centos branch : cmake.log
I unistalled/installed conan (pip unistall, deleted .conan created in my repertory)
I finally had some time to look int this issue.
The problem arises because of the C++ abi used by default. I can compile code when I force conan to pull packages build with the old abi: cmake ../corsika/ -D_GLIBCXX_USE_CXX11_ABI=OFF This way, the configuration compiler.libcxx=libstdc++ gets used instead of compiler.libcxx=libstdc++11
The code builds, but I get segmentation faults when running the tests. I'm not sure what happens there. It could be a problem in the internals of the sdplog binary or a problem of the old libstdc++ used by CentOS 7. Could be moving an object, which is new in c++11 and probably has no support in the old libstdc++. At least the context of the bug, looking a a stack trace in gdb, suggests that c++ would move a string there.
The problem occurs with devtoolsets 7, 8, and 9. I tried to pull in the header-only version of spdlog adding
[options] spdlog:header_only=True fmt:header_only=Trueto the conanfile.txt. But it doesn't seem to help.
Things (more or less) work If I use the new ABI and a compiler that doesn't try to remain compatible with the system libraries on CentOS 7. I tried with gcc 8.3.0.1 from /cvmfs/sft.cern.ch/lcg/contrib/gcc/8.3.0.1/x86_64-centos7 which was the easiest to try, since I have access to cvmfs on my centos 7 box.
I get a segfault in testModules both on my debian box and on centos 7. Not sure if I did something wrong with the submodules - the fault happens testing qgsjet II
created merge request !323 (merged) to address this issue
mentioned in merge request !323 (merged)
assigned to @lukas
closed with merge request !323 (merged)
mentioned in commit 5e3a9b43
Saving comments from Lukas:
In the case which I ran with gdb, the problem occurs when corsika sets up the default pattern for the logger:
/home/lukas/CORSIKA8/corsika/corsika/detail/framework/core/Logging.inl:50 logger->set_pattern(logging::default_pattern);As far as I can see from the code, this would involve a move constructor or move assign for the string representing the default pattern. The part of the stack trace in the system libraries suggests a memory leak:
#0 std::string::_Rep::_M_is_leaked (this=0xffffffffffffffe8) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h:3190 #1 0x000000000045751c in std::string::_Rep::_M_grab (this=0xffffffffffffffe8, __alloc1=..., __alloc2=...) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h:3241 #2 0x000000000044934a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string ( this=0x7fffffffddf8, __str=<error reading variable: Cannot access memory at address 0xffffffffffffffe8>) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.tcc:613 #3 0x00000000004cd20d in corsika::create_logger (name="corsika", defaultlog=true) at /home/lukas/CORSIKA8/corsika/corsika/detail/framework/core/Logging.inl:50which makes me suspect a problem with moving objects, since that is a new operation in C++ 11. I therefore suspect that the old, pre C++ implementation of string, used in the old ABI, doesn't implement the necessary operations correctly.
In the GCC 5.1 release libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list.The compiler (and accompanying libstdc++) on CentOS is 4.8.5, i.e., it predates the ABI changes. The devtoolset compilers from the software collection are built to maintain run-time compatibility so the compiled code can run also on machines w/o the devtoolset installed. To achieve this, they use the libraries in the core CentOS and not new libraries. Which is the longer explanation why we have to build with the old ABI on CentOS 7.
So what all this means: I don't think the segfault is directly linked to spdlog, it just happens to include code that triggers the bug. The problem happens even when I use the header-only version of spdlog, which contains no code build on a different platform.
more from Lukas, as implemented in !323 (merged)
... and I found a way to fix the problem: make a non-const string and pass it to setting the pattern. I'll make a branch now to deal with the problem. Found a better way, which detects the use of a compiler from the SCL. Seems to work and is merged now. Please try building again on CentOS 7
Edited by Johan BregeonRough guide lines to build on CentOS7:
- have python3, pip3 (pip from python3) and cmake3 available (different repositories propose these)
- conan must be installed with pip3
- use a devtools-set: versions 7, 8 and 9 have been tested for this issue.
Build instructions look then like (on a personal laptop, may differ on a computing center):
pip3 install --user conan source /opt/rh/devtoolset-9/enable mkdir work_dir cd work_dir git clone --recursive git@gitlab.ikp.kit.edu:AirShowerPhysics/corsika.git mkdir corsika-build cd corsika-build cmake3 ../corsika -DCMAKE_INSTALL_PREFIX=../corsika-install make -j 8 make install export CORSIKA_DATA=(path_to)work_dir/corsika/modules/data make test-
Ok, great. I will include this into the README for others !324 (merged)
If you like, you can close this Issue now, create a follow-up, or leave it open. Whatever is best.
