I'm getting an error I've never seen before. The GNU Fortran compiler (gfortran-mp-4.8) is tripping over the use of "_##" in variable names, which are being generated via the build process. I'm familiar with underscores being an extension, however I've never seen pound signs before in variable names and I can't find any statements online as to these characters being allowed.
Presumably this is an extension that I need to enable -- any suggestions? I've already got -std=gnu enabled.*
Eclipse > Mojave > Build...
/usr/bin/python simfactory/lib/sim.py build --mdbkey=make -j 8 --verbose bruiser --thornlist /Users/shawley/ThornLists/ThornListBruiser --optionlist /Users/shawley/options.bruiser.mac
IN DIRECTORY: /Users/shawley/Cactus
...snip...
COMPILING /Users/shawley/Cactus/arrangements/CactusBase/Fortran/src/paramcheck.F90
Warning: Nonexistent include directory "/Users/shawley/Cactus/arrangements/CactusBase/Fortran/src/include"
Warning: Nonexistent include directory "/Users/shawley/Cactus/arrangements/CactusBase/Fortran/src/include"
/Users/shawley/.mojaveconfig/Cactus/bruiser/build/Fortran/paramcheck.f90:6.34:
integer, parameter :: cctki_use_##cctk_dim = kind(cctk_dim)
1
Error: PARAMETER at (1) is missing an initializer
Two more questions:
1. What is the simfactory analog of "SILENT=no"? I see "--verbose" is already enabled, yet I'd like to see exactly what command (& flags) is being used to invoke the Fortran compiler.
2. Can the warning re. no "include" directory be safely ignored?
Thanks,
Scott
* GNU Fortran manual, page 41: "...By default, '-std=gnu' allows the compiler to accept both types of extensions..."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Scott,
integer, parameter :: cctki_use_##cctk_dim = kind(cctk_dim)
The Fortran compiler should never see these since they should be acted on by the C preprocessor which is used by Cactus to preprocess Fortran files. It should replace cctki_use_##cctk_dim by cctki_use_cctk_dim . I vaguely remember having seen a warning at one point that ## needs to be surrounded by whitespace. Are you using a very new gcc compiler maybe (gcc seems to become stricter with each release). You can try and change Cactus/src/include/cctk_Types.h to put a space around ## in
integer, parameter :: cctki_use_##nam = kind(nam)
ie turn it into
integer, parameter :: cctki_use_ ## nam = kind(nam)
I'd also check for warnings from the C preprocessor. You can also check your optionlist to make sure FPP is set to either cpp or cpp.pl . The later is Cactus' replacement C preprocessor.
Two more questions:
- What is the simfactory analog of "SILENT=no"? I see
"--verbose" is already enabled, yet I'd like to see exactly what command (& flags) is being used to invoke the Fortran compiler.
No idea really. You can try to circumvent simfactory and do (bash):
SILENT=no sim build
- Can the warning re. no "include" directory be safely ignored?
Yes.
Yours, Roland
- -- 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.
Roland, Thanks for your response.
Yes it is a very new GNU compiler.
I tried altering the relevant line in Cactus/src/include/cctk_Types.h. Adding a space before & after the ## changed the error such that the variable name now gets broken into two bits with a space in between, with the ## still there Also, making the '##' into a '/**/' as in the other relevant line, also produces a variable name broken by a single space.
Swapping out the usual cpp by setting "FPP = ~/Cactus/lib/sbin/cpp.pl" fixed the issue at hand, but produced a new set of issues regarding multi-line equations. Such as: - Maple generates a '#' in column 6 as a line-extension character. The cpp.pl seems to think that this is an "invalid preprocessing directive" even though the symbol is at column 6 instead of column 1. It is possible for me to replace " #" with " &" in all my files... ...in fact I've now done that, but there are still errors from other Thorns, such as... - In ADM/DoubleLeap, multi-line equations are getting mangled. I saw some users-email-list traffic about phasing out thorn ADM, but am not ready to make that change yet. (I want to get my thorn working before reconfiguring so much of it which inherits from ADM.).
Since many thorns in Cactus have multi-line equations, I'm not sure if using the cpp.pl script is an option for me.---Have other people not reported this problem?
Thanks for the answers re verbosity and the include directory!
-Scott
,
integer, parameter :: cctki_use_##cctk_dim = kind(cctk_dim)
The Fortran compiler should never see these since they should be acted on by the C preprocessor which is used by Cactus to preprocess Fortran files. It should replace cctki_use_##cctk_dim by cctki_use_cctk_dim . I vaguely remember having seen a warning at one point that ## needs to be surrounded by whitespace. Are you using a very new gcc compiler maybe (gcc seems to become stricter with each release). You can try and change Cactus/src/include/cctk_Types.h to put a space around ## in
integer, parameter :: cctki_use_##nam = kind(nam)
ie turn it into
integer, parameter :: cctki_use_ ## nam = kind(nam)
I'd also check for warnings from the C preprocessor. You can also check your optionlist to make sure FPP is set to either cpp or cpp.pl . The later is Cactus' replacement C preprocessor.
Two more questions:
- What is the simfactory analog of "SILENT=no"? I see
"--verbose" is already enabled, yet I'd like to see exactly what command (& flags) is being used to invoke the Fortran compiler.
No idea really. You can try to circumvent simfactory and do (bash):
SILENT=no sim build
- Can the warning re. no "include" directory be safely ignored?
Yes.
Yours, Roland
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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlKzz9EACgkQTiFSTN7SboXMFACfcRQQ2Hoxo3c0nK2om7yJhyWA XA0AnRHbpi4Kkun8Usp9MjGeErSTv7xE =4L+o -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Scott,
Since many thorns in Cactus have multi-line equations, I'm not sure if using the cpp.pl script is an option for me.---Have other people not reported this problem?
Uhm, I think I should have given a slightly different suggestion re cpp. Please try "cpp --traditional" for FPP. The behaviour that you observed (turning the comment into a space when using /**/ ) is the ANSI C behaviour ( the standard requires this) while what we want is what pre-ANSI compilers used to do (remove comments without trace).
a ## b
should be turned into
ab
as the ANSI standard requires that whitespace surrounding ## is removed. Not sure why this does not happen, but FPP=cpp --traditional should do the trick (and is in fact the setting that you will find in simfactory's option lists, if not please report the file, it is a bug).
Yours, Roland
- -- 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.
Aha! That's the missing piece.
Also, FWIW, apparently in Apple's latest OS "Mavericks", cpp does not support macro concatenation via ## like the true GNU compilers do. (I tested this; I copied and pasted example source from the GNU manual.) Furthermore it ignores the "--traditional" flag, i.e. generates no warning or error if you supply the flag, but it has no effect on the behavior.
So! Problem solved. The fix is to specify FPP= in the options file with the --traditional flag, using a true GNU compiler such as from MacPorts. No modifications to cctk_Types.h is necessary.
Thanks Roland!
-Scott
On Dec 20, 2013, at 12:28 AM, "Roland Haas" roland.haas@physics.gatech.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Scott,
Since many thorns in Cactus have multi-line equations, I'm not sure if using the cpp.pl script is an option for me.---Have other people not reported this problem?
Uhm, I think I should have given a slightly different suggestion re cpp. Please try "cpp --traditional" for FPP. The behaviour that you observed (turning the comment into a space when using /**/ ) is the ANSI C behaviour ( the standard requires this) while what we want is what pre-ANSI compilers used to do (remove comments without trace).
a ## b
should be turned into
ab
as the ANSI standard requires that whitespace surrounding ## is removed. Not sure why this does not happen, but FPP=cpp --traditional should do the trick (and is in fact the setting that you will find in simfactory's option lists, if not please report the file, it is a bug).
Yours, Roland
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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlKz45gACgkQTiFSTN7SboXDngCfaN5A8y1OyNHyn1dv/HmT+W0A vdcAn0/86+A7UeSnYbOI6589gSc7dSF1 =Lk+p -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 20 Dec 2013, at 07:58, Scott Hawley scott.hawley@belmont.edu wrote:
Aha! That's the missing piece.
Also, FWIW, apparently in Apple's latest OS "Mavericks", cpp does not support macro concatenation via ## like the true GNU compilers do. (I tested this; I copied and pasted example source from the GNU manual.) Furthermore it ignores the "--traditional" flag, i.e. generates no warning or error if you supply the flag, but it has no effect on the behavior.
So! Problem solved. The fix is to specify FPP= in the options file with the --traditional flag, using a true GNU compiler such as from MacPorts. No modifications to cctk_Types.h is necessary.
Thanks Roland!
Hi Scott,
We usually find that the apple compilers are not suitable for compiling the ET; we support using MacPorts using the simfactory optionlists, as this provides a single way to install all the required compilers and components. It's possible that we could make the apple compilers work, but there are other projects which have a higher priority.
On Dec 20, 2013 5:51 AM, "Ian Hinder" ian.hinder@aei.mpg.de wrote:
On 20 Dec 2013, at 07:58, Scott Hawley scott.hawley@belmont.edu wrote:
Aha! That's the missing piece.
Also, FWIW, apparently in Apple's latest OS "Mavericks", cpp does not
support macro concatenation via ## like the true GNU compilers do. (I tested this; I copied and pasted example source from the GNU manual.) Furthermore it ignores the "--traditional" flag, i.e. generates no warning or error if you supply the flag, but it has no effect on the behavior.
So! Problem solved. The fix is to specify FPP= in the options file
with the --traditional flag, using a true GNU compiler such as from MacPorts. No modifications to cctk_Types.h is necessary.
Thanks Roland!
Hi Scott,
We usually find that the apple compilers are not suitable for compiling
the ET; we support using MacPorts using the simfactory optionlists, as this provides a single way to install all the required compilers and components. It's possible that we could make the apple compilers work, but there are other projects which have a higher priority.
One possible explanation for the issue with the Apple compiler is that at some point relatively recently they switched from GCC to llvm as the compiler bundled with xcode. So it's possible that it's an issue with the version of llvm rather than purely an Apple issue.
There are also other reasons for supporting MacPorts GCC instead of the Apple compiler. Probably the biggest one is that the Apple compiler doesn't support Fortran, so as soon as you encounter a thorn which uses Fortran code your build would fail.
Barry
Yea, I've been specifying MacPorts executables for all compilers for a while now, but never knew about specifying the "Fortran pre-processor" until now. I guess it's been defaulting to the Apple pre-processor all this time without prior incident.
On Dec 20, 2013, at 4:51 AM, "Ian Hinder" <ian.hinder@aei.mpg.demailto:ian.hinder@aei.mpg.de> wrote:
On 20 Dec 2013, at 07:58, Scott Hawley <scott.hawley@belmont.edumailto:scott.hawley@belmont.edu> wrote:
Aha! That's the missing piece.
Also, FWIW, apparently in Apple's latest OS "Mavericks", cpp does not support macro concatenation via ## like the true GNU compilers do. (I tested this; I copied and pasted example source from the GNU manual.) Furthermore it ignores the "--traditional" flag, i.e. generates no warning or error if you supply the flag, but it has no effect on the behavior.
So! Problem solved. The fix is to specify FPP= in the options file with the --traditional flag, using a true GNU compiler such as from MacPorts. No modifications to cctk_Types.h is necessary.
Thanks Roland!
Hi Scott,
We usually find that the apple compilers are not suitable for compiling the ET; we support using MacPorts using the simfactory optionlists, as this provides a single way to install all the required compilers and components. It's possible that we could make the apple compilers work, but there are other projects which have a higher priority.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
users@lists.einsteintoolkit.org
-
Barry Wardell -
Ian Hinder -
Roland Haas -
Scott Hawley