Hey folks, I've been having some problems compiling the current master version of SuperLU_DIST and I've managed to trace the problem back to a bug introduced a few months ago in response to issue #183 "setenv SUPERLU_MAX_BUFFER_SIZE limited". Luckily, it appears to be an easy fix.
When compiling the Fortran bindings, make is told to compile target f_5x5, which requires the compilation of sp_ienv.c. This is a simple script that only implements one function, sp_ienv_dist. The problem is that there are two versions of sp_ienv.c: One is in SRC/prec-independent, and the other is in FORTRAN. They used to be essentially the same file, but as of the fix for #183 they are quite different, and critically have different return types (the FORTRAN version still returns int instead of the new int_t). By the time make gets to f_5x5 (at 98% compilation completion) it has already compiled both the SRC version as well as superlu_defs.h in SRC/include, which defines the return type of sp_ienv_dist as int_t in accordance with the SRC version of the file. The compiler sees that superlu_defs.h and the FORTRAN version of sp_ienv_dist don't agree on return type, and compilation fails as a result.
/home/marti990/Assembler/auto-installed-dependencies/SuperLU_DIST/superlu_dist-master/FORTRAN/sp_ienv.c:78:1: error: conflicting types for 'sp_ienv_dist'; have 'int(int, superlu_dist_options_t *)'
78 | sp_ienv_dist(int ispec, superlu_dist_options_t *options)
| ^~~~~~~~~~~~
In file included from /home/marti990/Assembler/auto-installed-dependencies/SuperLU_DIST/superlu_dist-master/SRC/include/superlu_ddefs.h:37,
from /home/marti990/Assembler/auto-installed-dependencies/SuperLU_DIST/superlu_dist-master/FORTRAN/sp_ienv.c:18:
/home/marti990/Assembler/auto-installed-dependencies/SuperLU_DIST/superlu_dist-master/SRC/include/superlu_defs.h:1105:15: note: previous declaration of 'sp_ienv_dist' with type 'int_t(int, superlu_dist_options_t *)' {aka 'long int(int, superlu_dist_options_t *)'}
1105 | extern int_t sp_ienv_dist (int, superlu_dist_options_t *);
| ^~~~~~~~~~~~
make[2]: *** [FORTRAN/CMakeFiles/f_5x5.dir/build.make:95: FORTRAN/CMakeFiles/f_5x5.dir/sp_ienv.c.o] Error 1
Luckily, it seems sp_ienv.c isn't used very much in the Fortran bindings directory, and I found that simply replacing the file with the SRC version causes compilation to succeed.
Relatedly, it seems that the Python bindings also haven't been updated to reflect the sp_ienv_dist return type change. I'm not using these and have not compiled them, but a cursory grep of the directory reveals that pdbridge.c calls sp_ienv_dist 3 times, two of which assume the old int return type. I'm guessing these would also fail to compile for the same reason.
Hey folks, I've been having some problems compiling the current master version of SuperLU_DIST and I've managed to trace the problem back to a bug introduced a few months ago in response to issue #183 "setenv SUPERLU_MAX_BUFFER_SIZE limited". Luckily, it appears to be an easy fix.
When compiling the Fortran bindings, make is told to compile target
f_5x5, which requires the compilation ofsp_ienv.c. This is a simple script that only implements one function,sp_ienv_dist. The problem is that there are two versions ofsp_ienv.c: One is inSRC/prec-independent, and the other is inFORTRAN. They used to be essentially the same file, but as of the fix for #183 they are quite different, and critically have different return types (theFORTRANversion still returnsintinstead of the newint_t). By the time make gets tof_5x5(at 98% compilation completion) it has already compiled both theSRCversion as well assuperlu_defs.hinSRC/include, which defines the return type ofsp_ienv_distasint_tin accordance with theSRCversion of the file. The compiler sees thatsuperlu_defs.hand theFORTRANversion ofsp_ienv_distdon't agree on return type, and compilation fails as a result.Luckily, it seems
sp_ienv.cisn't used very much in the Fortran bindings directory, and I found that simply replacing the file with theSRCversion causes compilation to succeed.Relatedly, it seems that the Python bindings also haven't been updated to reflect the
sp_ienv_distreturn type change. I'm not using these and have not compiled them, but a cursory grep of the directory reveals thatpdbridge.ccallssp_ienv_dist3 times, two of which assume the oldintreturn type. I'm guessing these would also fail to compile for the same reason.