DrTimothyAldenDavis
commented
7 months ago Yes, it's intentional. I can't change it; if OpenBLAS is doing it differently, then it's OpenBLAS that's doing it something strange, not SuiteSparse.
My rule is simple: I take the blas name (sgemm or SGEMM) and tack on the suffix, and I let the cmake C-to-Fortran detector determine the final underscore (or other name mangling as needed).
What is the OpenBLAS name of the 64-bit sgemm? Is it sgemm_64_?
The C-to-Fortran interface detector in CMake creates 2 macros for me: one for handling names that already have an underscore (FortranCInterface_GLOBAL__MACRO) and one that handles names that don't (FortranCInterface_GLOBAL_MACRO). See https://cmake.org/cmake/help/latest/module/FortranCInterface.html .
Those macros will likely append a final underscore, because that's typically how C calls Fortran. I intentionally do not include that final underscore in my BLAS64_SUFFIX. I can't do that because it would be a double underscore.
So if the OpenBLAS name is sgemm_64_ then we have, in order, in my framework in SuiteSparse:
blas name: sgemm
suffix: _64
final underscore added by the cmake C-to-Fortran interface: _
and then that gets me the final name: sgemm_64_
If the C-to-Fortran interface requires all upper case then the name would instead by SGEMM_64_
OpenBLAS must be handling it differently, assuming that its symbols already have a final suffix because of Fortran. So I guess:
OpenBLAS name: sgemm_
suffix: 64_
but if so, then that's broken. It cannot be combined with the cmake auto-detection of how C calls Fortran, which is what I do. It assumes all Fortran names must have a final underscore.
In some Fortran compilers on Windows, there is no final underscore when C calls Fortran.
mmuetzel
when configuring OpenBLAS with
make SYMBOLSUFFIX=64_, I would expect I could use-DBLAS64_SUFFIX=64_in SuiteSparse 7.4.0 (with a patch from julia folks to actually make symbol suffix work), but apparently you gotta use_64.Is that intentional?