Cannot link in msys64/ucrt64 because of wrong linking with -lC:/pathToGOMP/libgomp.dll.a

[DimaLPorNLP]

The bug

$ make
[ 0%] Building C object SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/SuiteSparse_config.c.o
[ 0%] Linking C shared library msys-suitesparseconfig-7.dll
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/msys64/ucrt64/lib/libgomp.dll.a: Invalid argument
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/msys64/ucrt64/lib/libmingwthrd.a: Invalid argument
collect2.exe: error: ld returned 1 exit status
make[2]: *** [SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/build.make:97: SuiteSparse_config/msys-suitesparseconfig-7.dll] Error 1
make[1]: *** [CMakeFiles/Makefile2:367: SuiteSparse_config/CMakeFiles/SuiteSparseConfig.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

To Reproduce
After I enabled only a subset of packages in CMakeLists.txt by commenting the "all" line and specifying them individually

#set ( SUITESPARSE_ENABLE_PROJECTS "all" CACHE STRING
 #   "Semicolon-separated list of SuiteSparse projects to be built (${SUITESPARSE_KNOWN_PROJECTS}, or
\"all\")" )

set(SUITESPARSE_ENABLE_PROJECTS "suitesparse_config;amd;btf;camd;ccolamd;colamd;cholmod;cxsparse;ldl;k
lu;umfpack" CACHE STRING "Enable specific SuiteSparse projects")

I tried

$ cmake -DBLAS_LIBRARIES="/ucrt64/bin/libopenblas.dll"  -DLAPACK_LIBRARIES="/ucrt64/bin/libopenblas.dll"   ..
$ make

[mmuetzel]

[ 0%] Linking C shared library msys-suitesparseconfig-7.dll
...
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/msys64/ucrt64/lib/libgomp.dll.a: Invalid argument

It looks like you are building for a MSYS2 (i.e., Cygwin) target while trying to use a Windows linker to link to Windows libraries.
The msys- prefix for libraries indicates that the target is MSYS2 (i.e., Cygwin) not Windows. Something seems to be wrong with your build environment.

What does which gcc and which cmake return for you?

[DimaLPorNLP]

What does which gcc and which cmake return for you?

The default that come with msys2/UCRT64.

$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cmake --version
cmake version 3.30.5

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[mmuetzel]

I didn't ask for the output of gcc --version or cmake --version.
So again: What does which gcc and which cmake return for you?

[mmuetzel]

Additionally, you shouldn't edit the CMake files of SuiteSparse's build system. If you'd like to build just a subset of the SuiteSparse libraries, follow the example given in the README file:

To build only a subset of libraries, set SUITESPARSE_ENABLE_PROJECTS when configuring with CMake. E.g., to build and install CHOLMOD and CXSparse (including their dependencies), use the following commands:

    mkdir -p build && cd build
    cmake -DSUITESPARSE_ENABLE_PROJECTS="cholmod;cxsparse" ..
    cmake --build .
    sudo cmake --install .

[DimaLPorNLP]

I didn't ask for the output of gcc --version or cmake --version. So again: What does which gcc and which cmake return for you?

$ which gcc
/ucrt64/bin/gcc

$ which cmake
/usr/bin/cmake

[DimaLPorNLP]

Additionally, you shouldn't edit the CMake files of SuiteSparse's build system. If you'd like to build just a subset of the SuiteSparse libraries, follow the example given in the README file:

To build only a subset of libraries, set SUITESPARSE_ENABLE_PROJECTS when configuring with CMake. E.g., to build and install CHOLMOD and CXSparse (including their dependencies), use the following commands:

    mkdir -p build && cd build
    cmake -DSUITESPARSE_ENABLE_PROJECTS="cholmod;cxsparse" ..
    cmake --build .
    sudo cmake --install .

Sorry, but this is an old SuiteSparse habit since the Makefile days that hard to get rid of. But I find it much more convenient since it is easier to maintain because I cannot remember by heart which variable to set to what. This is the kind of complexity I find unacceptable which cmake. I have lost many days in the past to learn how to use it just to realize that it is another badly designed computer science project with a terrible learning curve similar to emacs, to be replaced soon by something more reasonable. I am happy that there are much more logical alternatives at the moment providing everything that cmake offers and much more readable as well. Check for example xmake.

[mmuetzel]

$ which cmake
/usr/bin/cmake

You are using a cmake that is meant to target the MSYS2 (Cygwin) environment. Try again after installing the cmake that matches your gcc. I.e., pacman -S mingw-w64-ucrt-x86_64-cmake.

[mmuetzel]

But I find it much more convenient since it is easier to maintain because I cannot remember by heart which variable to set to what. This is the kind of complexity I find unacceptable which cmake.

If that is what you are struggling with most, maybe cmake-gui is what you prefer. (I personally quite like the fact that I can set everything from the command line...)

[DimaLPorNLP]

OK I installed the ucrt64 cmake as you suggested.

$ cmake -DBLAS_LIBRARIES="/ucrt64/bin/libopenblas.dll"  -DLAPACK_LIBRARIES="/ucrt64/bin/libopenblas.dll"  ..
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /ucrt64/bin/cc.exe
-- Check for working C compiler: /ucrt64/bin/cc.exe - broken
CMake Error at /ucrt64/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/ucrt64/bin/cc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/home/mac/SuiteSparse/build/CMakeFiles/CMakeScratch/TryCompile-qdlVoU'

    Run Build Command(s): /ucrt64/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.exe -f Makefile cmTC_eed1b/fast
    /usr/bin/make  -f CMakeFiles/cmTC_eed1b.dir/build.make CMakeFiles/cmTC_eed1b.dir/build
    make[1]: Entering directory '/home/mac/SuiteSparse/build/CMakeFiles/CMakeScratch/TryCompile-qdlVoU'
    Building C object CMakeFiles/cmTC_eed1b.dir/testCCompiler.c.o
    /ucrt64/bin/cc.exe    -o CMakeFiles/cmTC_eed1b.dir/testCCompiler.c.o -c /home/mac/SuiteSparse/build/CMakeFiles/CMakeScratch/TryCompile-qdlVoU/testCCompiler.c
    Linking C executable cmTC_eed1b.exe
    /ucrt64/bin/cmake.exe -E cmake_link_script CMakeFiles/cmTC_eed1b.dir/link.txt --verbose=1
    /ucrt64/bin/cc.exe -Wl,--enable-auto-import  CMakeFiles/cmTC_eed1b.dir/testCCompiler.c.o -o cmTC_eed1b.exe -Wl,--out-implib,libcmTC_eed1b.dll.a -Wl,--major-image-version,0,--minor-image-version,0
    Error running link command: no such file or directorymake[1]: *** [CMakeFiles/cmTC_eed1b.dir/build.make:99: cmTC_eed1b.exe] Error 2
    make[1]: Leaving directory '/home/mac/SuiteSparse/build/CMakeFiles/CMakeScratch/TryCompile-qdlVoU'
    make: *** [Makefile:127: cmTC_eed1b/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:24 (project)


-- Configuring incomplete, errors occurred!

[mmuetzel]

Delete your build directory (with all files that were created when you used the wrong cmake), and start again.

[mmuetzel]

Fwiw, here is the configure command that I use most of the time when building in SuiteSparse in MSYS2:

cmake -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=Release -DBLA_VENDOR=OpenBLAS -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_Fortran_COMPILER_LAUNCHER=ccache -DPython_EXECUTABLE=$(which python) ..

If you don't plan on building the libraries repeatedly, you can get rid of the *_COMPILER_LAUNCHER flags. If you don't care about running the ctests for the Mongoose library, you can also omit the Python_EXECUTABLE flag.
That would leave you with:

cmake -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=Release -DBLA_VENDOR=OpenBLAS ..

[DimaLPorNLP]

Delete your build directory (with all files that were created when you used the wrong cmake), and start again.

I do that every time before cmake. This is another reason why I do not like cmake.

[DimaLPorNLP]

Fwiw, here is the configure command that I use most of the time when building in SuiteSparse in MSYS2:

cmake -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=Release -DBLA_VENDOR=OpenBLAS ..

Same problem as before. I delete every time before cmaking:
rm -rf build/

[mmuetzel]

What does which cmake return for you now?
The default generator on Windows should be Ninja. But it looks like it is trying to create Makefiles. Your build environment is still screwed somehow...

[mmuetzel]

If you only want to use SuiteSparse but you are struggling to build it, it might be easier to use distributed binaries. E.g., from MSYS2: https://packages.msys2.org/base/mingw-w64-suitesparse
I.e., install them with pacman -S mingw-w64-ucrt-x86_64-suitesparse. (That is the latest released version currently - which is the same as the development branches right now.)

[DimaLPorNLP]

`

What does which cmake return for you now? The default generator on Windows should be Ninja. But it looks like it is trying to create Makefiles. Your build environment is still screwed somehow...

if you see the output I pasted above it clearly shows that it runs the new cmake we installed recently.

$ which cmake
/ucrt64/bin/cmake

[mmuetzel]

What is which ninja?

[mmuetzel]

What is echo $PATH for you? Are there competing toolchains in your PATH?

[DimaLPorNLP]

$ which ninja
/ucrt64/bin/ninja

$ echo $PATH
/ucrt64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

[DimaLPorNLP]

If you only want to use SuiteSparse but you are struggling to build it, it might be easier to use distributed binaries. E.g., from MSYS2: https://packages.msys2.org/base/mingw-w64-suitesparse I.e., install them with pacman -S mingw-w64-ucrt-x86_64-suitesparse. (That is the latest released version currently - which is the same as the development branches right now.)

The reason I am doing all these is that I want to add a function to KLU to monitor the memory allocated through a function call because I am using KLU from .NET. I do not know how to write in .NET an interface to the Common structure but it is relatively easy to add an interface to a function. But I was not able to find such a function in KLU.

[mmuetzel]

Maybe, write a small function in C that does that for you. I don't know much about .NET. But surely it can link to objects written in C and use functions that are declared in it. Can it?

But by the looks of it, either your compiler or your linker (or something else) doesn't work. Have a look at the CMakeConfigureLog.yaml file in the CMakeFiles directory of your build tree. Maybe, there are some clues in there.

(Another idea: You wouldn't be the first for which a overzealous virus scanner deleted something important. Which are you using?)

[DimaLPorNLP]

Maybe, write a small function in C that does that for you. I don't know much about .NET. But surely it can link to objects written in C and use functions that are declared in it. Can it?

But by the looks of it, either your compiler or your linker (or something else) doesn't work. Have a look at the CMakeConfigureLog.yaml file in the CMakeFiles directory of your build tree. Maybe, there are some clues in there.

(Another idea: You wouldn't be the first for which a overzealous virus scanner deleted something important. Which are you using?)

No, this is a brand new laptop.

[DimaLPorNLP]

If you only want to use SuiteSparse but you are struggling to build it, it might be easier to use distributed binaries. E.g., from MSYS2: https://packages.msys2.org/base/mingw-w64-suitesparse I.e., install them with pacman -S mingw-w64-ucrt-x86_64-suitesparse. (That is the latest released version currently - which is the same as the development branches right now.)

.NET cannot link to objects it uses shared objects opens the .dll or .so object. This is not the problem. This is doable.

[DimaLPorNLP]

Maybe, write a small function in C that does that for you. I don't know much about .NET. But surely it can link to objects written in C and use functions that are declared in it. Can it?

But by the looks of it, either your compiler or your linker (or something else) doesn't work. Have a look at the CMakeConfigureLog.yaml file in the CMakeFiles directory of your build tree. Maybe, there are some clues in there.

(Another idea: You wouldn't be the first for which a overzealous virus scanner deleted something important. Which are you using?)

This problem we ran into has been reported in other context. It seems it is a problem with the ninja of ucrt64.
You may find a similar discussion here

[DimaLPorNLP]

After, reinstalling ninja for ucrt64 and updating the whole system using

pacman -Syu

and reinstalling ninja, make, cmake after the previous command, the cmake command mentioned that it generates ninja files instead of Makefiles. It is important to reinstall ucrt64/mingw-w64-ucrt-x86_64-make although it may say that it is already installed.

$ cmake -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=Release -DBLA_VENDOR=OpenBLAS ..
-- Building for: Ninja
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info

It configured correctly without issues and the command ninja finished the build process and ninja install finished the install process without any issues. I still do not know how cmake used ninja instead of makefiles, probably ninja was not installed on my system. Therefore it seems that cmake has problems with Makefiles on ucrt64. However, on msys2/clang64 I was able to compile without issues without the ninja. CMAKE works with makefiles on clang64 environment even without using clang compilers because they are not installed, but it does not configure properly on the ucrt64 environment. It is not clear to me why since both run under windows and they are subject to the same backslash problems which is windows specific. Other than that, I guess that the problem is solved because I found out that it is not a problem of SuiteSparse but of cmake-Makefiles under ucrt64.

[DrTimothyAldenDavis]

shall I close this issue as resolved?

[DimaLPorNLP]

I updated the instructions in my previous reply. The key point I missed was to reinstall also ucrt64/mingw-w64-ucrt-x86_64-make although it is already installed. You many now close the issue as resolved.