undefined reference to `GB_JITpackage_nfiles`

[jschueller]

Describe the bug graphblas fails to link when cross-compiling, it seems some native target generating that source file is not triggered: https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/dev/GraphBLAS/JITpackage/CMakeLists.txt#L68

To Reproduce use mingw from linux

Expected behavior links succeeds

Screenshots

[ 95%] Linking C shared library libgraphblas.dll
/usr/lib/gcc/i686-w64-mingw32/13.2.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/GraphBLAS.dir/objects.a(GB_jitifyer.c.obj):GB_jitifyer.c:(.text+0x218e): undefined reference to `GB_JITpackage_nfiles'
/usr/lib/gcc/i686-w64-mingw32/13.2.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/GraphBLAS.dir/objects.a(GB_jitifyer.c.obj):GB_jitifyer.c:(.text+0x21a7): undefined reference to `GB_JITpackage_index'
/usr/lib/gcc/i686-w64-mingw32/13.2.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/GraphBLAS.dir/objects.a(GB_jitifyer.c.obj):GB_jitifyer.c:(.text+0x21d4): undefined reference to `GB_JITpackage_nfiles'
/usr/lib/gcc/i686-w64-mingw32/13.2.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/GraphBLAS.dir/objects.a(GB_jitifyer.c.obj):GB_jitifyer.c:(.text+0x21e5): undefined reference to `GB_JITpackage_index'
/usr/lib/gcc/i686-w64-mingw32/13.2.1/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/GraphBLAS.dir/objects.a(GB_jitifyer.c.obj):GB_jitifyer.c:(.text+0x2279): undefined reference to `GB_JITpackage_nfiles'
collect2: error: ld returned 1 exit status

Desktop (please complete the following information):

• OS: Linux
• compiler mingw-w64-gcc 13.2.1
• netlib blas/lapack 3.12.0
• Version 7.5.0

Additional context configuring with cmake -DSUITESPARSE_DEMOS=OFF -DBUILD_TESTING=OFF -DBLA_VENDOR=Generic ..., make install

succeeds if I disable jit: cmake -DGRAPHBLAS_USE_JIT=OFF

/cc @mmuetzel

[mmuetzel]

Hmmm... Another wild guess: To check if it is any of the flags added in x86_64-w64-mingw32-cmake, does replacing /usr/bin/x86_64-w64-mingw32-cmake with cmake -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake -DCMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES:PATH=/usr/x86_64-w64-mingw32/include make a difference?

That's based on the file found here: https://aur.archlinux.org/cgit/aur.git/tree/mingw-cmake.sh?h=mingw-w64-cmake

[jschueller]

I can even configure directly with: cmake -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-x86_64-w64-mingw32.cmake . but the error is the same

[mmuetzel]

Does it work if you "fake" a cross-compilation? I.e., something like (no actual cross-compilers involved):

cmake -DCMAKE_SYSTEM_NAME="Linux" .
make GB_JITpackage

[jschueller]

this one works

[mmuetzel]

Ok. Another wild guess: Could that be a consequence of set (CMAKE_FIND_ROOT_PATH /usr/@TRIPLE@) in combination with set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) in the toolchain file? Does it work if you comment out the latter line in the toolchain file?

[jschueller]

oh yes that's totally it

[mmuetzel]

Nice.

I kind of understand why the ArchLinux packagers chose to add that line to their toolchain file. But I'm not sure if it's a good idea to set the CMAKE_FIND_ROOT_PATH_MODE_* variables to ONLY for everyone...

[jschueller]

I guess it can be useful not to pick config files from the host environment when not available in the target environment

[mmuetzel]

Might also be an issue in CMake. Reading the documentation doesn't immediately tell that PATHS hints are ignored when it it set to ONLY: https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH_MODE_PACKAGE.html

Maybe, report upstream?

As a workaround it might be possible to override that flag from the toolchain file with -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=BOTH in the configure flags?

[jschueller]

on the other end it says that ONLY_CMAKE_FIND_ROOT_PATH only search in CMAKE_STAGING_PREFIX but I guess thats a typo and they meant CMAKE_FIND_ROOT_PATH, so its consistent with what we're seeing

[mmuetzel]

The documentation also says: https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package

The default behavior can be adjusted by setting CMAKE_FIND_ROOT_PATH_MODE_PACKAGE. This behavior can be manually overridden on a per-call basis using options:

CMAKE_FIND_ROOT_PATH_BOTH Search in the order described above.

NO_CMAKE_FIND_ROOT_PATH Do not use the CMAKE_FIND_ROOT_PATH variable.

ONLY_CMAKE_FIND_ROOT_PATH Search only the re-rooted directories and directories below CMAKE_STAGING_PREFIX.

And then:

If NO_DEFAULTPATH is specified all NO* options are enabled.

So, iiuc, whatever value CMAKE_FIND_ROOT_PATH_MODE_PACKAGE has, it should not apply for that find_package command...

[jschueller]

i dont understand, could you maybe open a bug at cmake repo ?

[DrTimothyAldenDavis]

Is this fixed now, except for perhaps a bug in cmake itself?

[jschueller]

yes, maybe it could be worth to be reported at cmake to see if its a bug from their side