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 <[email protected]> To: Samuel Tootle <[email protected]> CC: [email protected] 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. _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
