DrTimothyAldenDavis / SuiteSparse

The official SuiteSparse library: a suite of sparse matrix algorithms authored or co-authored by Tim Davis, Texas A&M University.
https://people.engr.tamu.edu/davis/suitesparse.html
Other
1.11k stars 256 forks source link

Compiling GraphBLAS fails with `C11 atomics: failed` #818

Closed e-eight closed 1 month ago

e-eight commented 1 month ago

Describe the bug I am trying to compile SuiteSparse-7.7.0. Running cmake .. from the build directory fails at the Building SuiteSparse:GraphBLAS version: v9.1.0, date: Mar 22, 2024 step with the following error:

-- Performing Test TEST_FOR_STDATOMIC
-- Performing Test TEST_FOR_STDATOMIC - Failed
-- Performing Test TEST_FOR_STDATOMIC_WITH_LIBATOMIC
-- Performing Test TEST_FOR_STDATOMIC_WITH_LIBATOMIC - Failed
CMake Error at GraphBLAS/cmake_modules/SuiteSparseAtomic.cmake:53 (message):
  C11 atomics: failed
Call Stack (most recent call first):
  GraphBLAS/CMakeLists.txt:426 (include)

To Reproduce Run cmake .. from the build directory.

Expected behavior Expected the GraphBLAS module to compile

Screenshots image

Desktop (please complete the following information):

Additional context Trying to install this on a cluster.

mmuetzel commented 1 month ago

Could you please run cmake --fresh .. | tee cmake_config.log and upload that .log file here?

e-eight commented 1 month ago

Here is the log file. cmake_config.log

DrTimothyAldenDavis commented 1 month ago

Is there any way to get the output of the tests? It is in the GraphBLAS/cmake_modules/SuiteSparseAtomic.cmake file. GraphBLAS requires ANSI C11 support for atomic operations.

Try compiling this outside of the build system, with the compiler you used:

    // gcc, clang, icx, xlc, etc: see if -latomic is required
    #include <stdatomic.h>
    #include <stdint.h>
    int main (void)
    {
        _Atomic uint8_t t8 = 0 ;
        uint8_t e8 = 0, d8 = 0 ;
        atomic_compare_exchange_weak (&t8, &e8, d8) ;
        _Atomic uint16_t t16 = 0 ;
        uint16_t e16 = 0, d16 = 0 ;
        atomic_compare_exchange_weak (&t16, &e16, d16) ;
        _Atomic uint32_t t32 = 0 ;
        uint32_t e32 = 0, d32 = 0 ;
        atomic_compare_exchange_weak (&t32, &e32, d32) ;
        _Atomic uint64_t t64 = 0 ;
        uint64_t e64 = 0, d64 = 0 ;
        atomic_compare_exchange_weak (&t64, &e64, d64) ;
        return (0) ;
    }

Then try it with just gcc and then with gcc -latomic.

DrTimothyAldenDavis commented 1 month ago

gcc 8.3 is pretty old. That might be the problem.

mmuetzel commented 1 month ago

Thank you for the log.

It looks like you are building SuiteSparse with NVidia HPC (not with GCC).

Do you have the GCC Development Tools installed? See, e.g., https://forums.developer.nvidia.com/t/error-while-loading-shared-libraries-libatomic-so-1/213810

DrTimothyAldenDavis commented 1 month ago

It looks like you are building SuiteSparse with NVidia HPC (not with GCC).

Good catch -- I didn't notice that. I've never tried that compiler. It may also affect GraphBLAS later on.

GraphBLAS has an internal JIT that (by default) uses the same compiler used to compile GraphBLAS. It should configure itself properly once GraphBLAS is compiled correctly (see the SuiteSparse/GraphBLAS/Config/GB_config.h file), but you're in uncharted waters with that compiler. It's possible that could fail as well. Once you are able to compile GraphBLAS, try the demos and look at their raw output (build/gauss_demo.out and build/wildtype.out). If you run wildtype_demo again with

./build/wildtype_demo

the output should say "jit: cpu load" about 6 times. That would indicate that the first run of ./build/wild_type successfully compiled 6 JIT kernels and placed them in your ~/.SuiteSparse/GrB* folder, and then was able to simply load them the 2nd time you ran the demo.

e-eight commented 1 month ago

Thanks for the suggestions. Figured out what the problem was. I had some CUDA modules loaded, which automatically set CC, CXX, and FC to point to the NVidia compilers. After I disabled those, it still didn't build, because CMake then picked up an even older compiler, GCC 4.8.5.

Setting the CC, CXX, and FC variables to point to the GCC 8.3.0 compilers did the trick. Also had to add the path to the NVidia compilers to PATH so that CMake detects a CUDA compiler. The CMake part of the process works now.

DrTimothyAldenDavis commented 1 month ago

So can we close this issue now?

e-eight commented 1 month ago

Yes, please. Thanks again for all the help.