Hi Roland,
I'm using GCC on my laptop for testing. No special compilers.
It turned out to be quite simple. I had started from a clean cfg file to minimize the compiler options since I'm used to using Intel on HPC systems. I had ran into issues with compiling fortran codes and so I added -fno-underscore which resolved many of these issues until it didn't. I found out later that I needed to include:
FFLAGS= -traditional
But I had never removed the -fno-underscore. I still find it odd that all of the Cactus codes compile fine and only SummationByParts has compiler issues.
Cheers, Samuel
From: Roland Haas rhaas@illinois.edu To: Samuel Tootle tootle@itp.uni-frankfurt.de CC: users@einsteintoolkit.org Date: Feb 18, 2023 03:50:17 Subject: Re: [Users] SummationByParts c_file_processor issues
Hello Samuel,
Would this be using an "unusual" compiler? Namely the IBM compiler?
Cactus expects that Fortran adds at least one underscore to function names. That is a function visible in Fortran as "Foo" is visible to the linker (and C code) as Foo_.
If that is not the case then there can be a conflict in case (against what the docs say) there are:
void CCTK_FNAME(foo)(int *); void foo(int);
with the assumption that they are different (happens if eg the latter one is called by the former to provide its functionality).
Fixes:
- make your compiler add at least one underscore (for the IBM compiler
you may have to read the docs)
- name the functions CCTK_FNAME(Foo)(int *) and Foo(int). This will
work even without underscores since Fortran, being case insensitive, internally converts all names to lowercase (or uppercase, or thechnically lOwErCaSe would also work as long as the pattern is unique).
Also note that CCTK_FNAME can *only* be used in compiled files (*.c and *.cc files) not header files (*.h) even if the header are included in c files (all of them are anyway...).
See: http://einsteintoolkit.org/usersguide/UsersGuide.html#x1-130000C1.9.4
--8<-- void CCTK_FCALL CCTK_FNAME(<routine name>)(int *ierr, <argument list>) <rewrite routine code, or call C routine itself>
The convention used in Cactus, is that <routine name> be the same as any C routine name, and that this is mixed-case. The macros change the case and number of underscores of the routine name to match that expected by Fortran. --8<--
Yours, Roland
For the compiling gurus:
I've been working towards finalizing the FUKA importer build system for inclusion into the ETK and I've recently added additional thorns to the build list to run the test par. For completeness, I'm compiling in the following way:
yes | make test-config THORNLIST=thornlist/test.th options=test.cfg; make test:
Currently, all thorns compile successfully except for SummationByParts which gives the following error:
/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:49:17: error: redefinition of ‘get_shiftout’ 49 | void CCTK_FCALL CCTK_FNAME(get_shiftout)( const CCTK_POINTER_TO_CONST cctkGH_, | ^~~~~~~~~~~~ /home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:11:6: note: previous definition of ‘get_shiftout’ with type ‘void(const void * const, CCTK_INT4 *)’ {aka ‘void(const void * const, int *)’} 11 | void get_shiftout ( const CCTK_POINTER_TO_CONST cctkGH_,
What appears to be happening is that the c_file_processor.pl is not handling the generation of creating a fortran function in place of CCTK_FNAME so far as I understand it. For instance, if I check the `Cactus/configs/test/build/SummationByParts/get_offset.c` file, the CCTK_FNAME statement is still there. Conversely, if I check `Cactus/configs/test/build/Boundary/FlatBoundary.c` which also uses CCTK_FNAME, these statements have been correctly removed by the pre-processor.
Oddly enough, if I run `make test --just-print` I obtain the following which suggests that it is at least executing the processor correctly.
Checking status of thorn SummationByParts if [ ! -d ./ ] ; then mkdir -p ./ ; fi cd ./ ; make CCTK_TARGET=make.checked TOP=/home/user/lib/ETKREL/Cactus/configs/test CONFIG=/home/user/lib/ETKREL/Cactus/configs/test/config-data SRCDIR=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src THORN=SummationByParts USESTHORNS="" -f /home/user/lib/ETKREL/Cactus/lib/make/make.subdir{if test yes = 'yes'; then echo '#line 1 "'/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c'"'; fi; cat /home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c; } | perl -s /home/user/lib/ETKREL/Cactus/lib/sbin/c_file_processor.pl -line_directives=yes -source_file_name=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c /home/user/lib/ETKREL/Cactus/configs/test/config-data > get_offset.c echo COMPILING CactusNumerical/SummationByParts/src/get_offset.c
I have compared the above to the compilation of Boundary/src/FlatBoundary.c which compiles successfully and also includes the generation of a number of Fortran functions using CCTK_FNAME. So far, no discrepancies have been found that would highlight why summationbyparts is failing.
I will continue to try and resolve this, but I hope someone with more experience with the pre-processors will be able to shed some light on the issue.
Cheers,
Samuel
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.