Hello,
While setting up a local cluster, I've run into a problem I just don't understand when compiling. It seems that the compiler's not finding <math.h>! (for one program, at least) To this point, the compilation procedure has proceeded without trouble; I've successfully compiled on other machines.
Thoughts?
Thanks,
-Richard
PS: for reference, the compilation is below
[oshaughn@hydra Cactus]$ ./simfactory/sim build --thornlist=manifest/einsteintoolkit.th --optionlist=simfactory/optionlists/hydra.cfg </cut> Checking status of thorn LoopControl ________________________________________________________________________ Preprocessing /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c Compiling /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c: In function 'lc_demo': /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: 'M_PI' undeclared (first use in this function) /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: (Each undeclared identifier is reported only once /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: for each function it appears in.)
Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu 462 Physics Building Phone: 414 229 6674 Center for Gravitation and Cosmology University of Wisconsin, Milwaukee 53211
Richard
There are several dialects of C, and several common extensions. It turns out that M_PI is not part of the core C standard, but only of the POSIX standard. This doesn't mean much in practice, since POSIX (basically Unix) is available on all common systems. Your problem here is that your compiler, by default, doesn't enable POSIX.
What compiler and what version are you using? We have figured out what compiler options enable POSIX for most systems, so this may be easy to do.
-erik
On Fri, Oct 15, 2010 at 7:03 AM, Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu wrote:
Hello,
While setting up a local cluster, I've run into a problem I just don't understand when compiling. It seems that the compiler's not finding <math.h>! (for one program, at least) To this point, the compilation procedure has proceeded without trouble; I've successfully compiled on other machines.
Thoughts?
Thanks,
-Richard
PS: for reference, the compilation is below
[oshaughn@hydra Cactus]$ ./simfactory/sim build --thornlist=manifest/einsteintoolkit.th --optionlist=simfactory/optionlists/hydra.cfg
</cut> Checking status of thorn LoopControl ________________________________________________________________________ Preprocessing /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c Compiling /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c: In function 'lc_demo': /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: 'M_PI' undeclared (first use in this function) /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: (Each undeclared identifier is reported only once /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: for each function it appears in.) Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu 462 Physics Building Phone: 414 229 6674 Center for Gravitation and Cosmology University of Wisconsin, Milwaukee 53211
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Erik,
On this cluster, I get to use gcc 4.1.2. The optionlist file I've hacked together is below; please ignore the comments, as they are relics of the progenitor file.
By the way, Frank's suggestion works fine as a temporary patch -- not done yet, but I'm a good way through compilation without errors.
-Richard
VERSION = 2010-10-14
# PGI 9.0.3 works CPP = cpp FPP = cpp CC = gcc CXX = g++ F77 = gfortran F90 = gfortran
# -Mx,125,0x200: allow calling C varargs functions from Fortran CPPFLAGS = -DMPICH_IGNORE_CXX_SEEK -DM_PI='3.14159265358979323846264338327' FPPFLAGS = -traditional CFLAGS = -g3 -m128bit-long-double CXXFLAGS = -g3 -m128bit-long-double --exceptions -D_ISOC99_SOURCE -D_BSD_SOURCE F90FLAGS = -g3 -m128bit-long-double F77FLAGS = -g3 -m128bit-long-double
# Do not link against pgc when using OpenMP #LIBS = stdc++ crypt pgf90 pgf90rtl pgftnrtl pgf90_rpm1 pghpf2 rt m dl C_LINE_DIRECTIVES = yes F_LINE_DIRECTIVES = yes
DEBUG = no CPP_DEBUG_FLAGS = -DCARPET_DEBUG FPP_DEBUG_FLAGS = -DCARPET_DEBUG C_DEBUG_FLAGS = -O0 CXX_DEBUG_FLAGS = -O0 F77_DEBUG_FLAGS = -O0 F90_DEBUG_FLAGS = -O0
# For PGI 10.6 and later, add -Mautoinline=totalsize:500000 OPTIMISE = yes CPP_OPTIMISE_FLAGS = # @('@UNSAFE@' eq 'yes' ? '-DCARPET_OPTIMISE -DNDEBUG' : '')@ FPP_OPTIMISE_FLAGS = # @('@UNSAFE@' eq 'yes' ? '-DCARPET_OPTIMISE -DNDEBUG' : '')@ C_OPTIMISE_FLAGS = -O3 CXX_OPTIMISE_FLAGS = -O3 F90_OPTIMISE_FLAGS = -O3 F77_OPTIMISE_FLAGS = -O3
PROFILE = no CPP_PROFILE_FLAGS = FPP_PROFILE_FLAGS = C_PROFILE_FLAGS = -pg CXX_PROFILE_FLAGS = -pg F77_PROFILE_FLAGS = -pg F90_PROFILE_FLAGS = -pg
# Note: -mp=nonuma switches off --exceptions OPENMP = yes CPP_OPENMP_FLAGS = -D_OPENMP -fopenmp FPP_OPENMP_FLAGS = -D_OPENMP C_OPENMP_FLAGS = -fopenmp CXX_OPENMP_FLAGS = -fopenmp F77_OPENMP_FLAGS = -fopenmp F90_OPENMP_FLAGS = -fopenmp
WARN = yes CPP_WARN_FLAGS = FPP_WARN_FLAGS = C_WARN_FLAGS = CXX_WARN_FLAGS = F90_WARN_FLAGS = F77_WARN_FLAGS =
MPI = OpenMPI OPENMPI_DIR = /usr/lib64/openmpi/1.2.7-gcc OPENMPI_LIBS = mpi mpi_cxx open-rte open-pal
PTHREADS = yes
On Oct 15, 2010, at 9:44 AM, Erik Schnetter wrote:
Richard
There are several dialects of C, and several common extensions. It turns out that M_PI is not part of the core C standard, but only of the POSIX standard. This doesn't mean much in practice, since POSIX (basically Unix) is available on all common systems. Your problem here is that your compiler, by default, doesn't enable POSIX.
What compiler and what version are you using? We have figured out what compiler options enable POSIX for most systems, so this may be easy to do.
-erik
On Fri, Oct 15, 2010 at 7:03 AM, Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu wrote:
Hello,
While setting up a local cluster, I've run into a problem I just don't understand when compiling. It seems that the compiler's not finding <math.h>! (for one program, at least) To this point, the compilation procedure has proceeded without trouble; I've successfully compiled on other machines.
Thoughts?
Thanks,
-Richard
PS: for reference, the compilation is below
[oshaughn@hydra Cactus]$ ./simfactory/sim build --thornlist=manifest/einsteintoolkit.th --optionlist=simfactory/optionlists/hydra.cfg
</cut> Checking status of thorn LoopControl ________________________________________________________________________ Preprocessing /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c Compiling /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c: In function 'lc_demo': /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: 'M_PI' undeclared (first use in this function) /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: (Each undeclared identifier is reported only once /home/oshaughn/Numerical/EinsteinToolkit/Cactus/arrangements/Carpet/LoopControl/src/wavetoy-loopcontrol.c:183: error: for each function it appears in.) Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu 462 Physics Building Phone: 414 229 6674 Center for Gravitation and Cosmology University of Wisconsin, Milwaukee 53211
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu 462 Physics Building Phone: 414 229 6674 Center for Gravitation and Cosmology University of Wisconsin, Milwaukee 53211
On Fri, Oct 15, 2010 at 11:45 AM, Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu wrote:
Hello Erik, On this cluster, I get to use gcc 4.1.2. The optionlist file I've hacked together is below; please ignore the comments, as they are relics of the progenitor file. By the way, Frank's suggestion works fine as a temporary patch -- not done yet, but I'm a good way through compilation without errors.
What is Frank's suggestion?
-erik
On Fri, Oct 15, 2010 at 11:45 AM, Richard O'Shaughnessy oshaughn@gravity.phys.uwm.edu wrote:
Hello Erik, On this cluster, I get to use gcc 4.1.2. The optionlist file I've hacked together is below; please ignore the comments, as they are relics of the progenitor file.
gcc 4.1 doesn't have a good gfortran; I suggest to use at least gcc 4.2 if you have Fortran code. I'm using gcc 4.5 myself.
For gcc 4.5, I use the option -std=gnu99 for C and -std=gnu++0x for C++. These may do the trick.
-erik
users@lists.einsteintoolkit.org