Problem installing PRESTO with Apple M2 - Ventura 13.2

[andsanna]

I'm trying to install PRESTO on my Apple M2 laptop where it's installed os Ventura 13.2
Gfortran 12.2

./configure seems to run smoothly

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... ./config/install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking for gfortran... gfortran
checking whether the compiler supports GNU Fortran 77... yes
checking whether gfortran accepts -g... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for malloc.h... no
checking build system type... aarch64-apple-darwin22.3.0
checking host system type... aarch64-apple-darwin22.3.0
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran...  -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/12 -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc -L/opt/homebrew/Cellar/gcc/12.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/12/../../.. -lgfortran -lemutls_w -lquadmath
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking if sgemm_ is being linked in already... no
checking for sgemm_ in -lopenblas... no
checking for ATL_xerbla in -latlas... no
checking for sgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for sgemm_ in -lmkl... no
checking for sgemm_ in -framework vecLib... no
checking for sgemm_ in -lcxml... no
checking for sgemm_ in -ldxml... no
checking for sgemm_ in -lscs... no
checking for sgemm_ in -lcomplib.sgimath... no
checking for sgemm_ in -lblas... (cached) yes
checking for sgemm_ in -lessl... no
checking for sgemm_ in -lblas... (cached) yes
checking for cheev_... no
checking for cheev_ in -llapack... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating tempo.cfg
config.status: creating src/config.h
config.status: creating clock/Makefile
config.status: creating ephem/Makefile
config.status: creating test/Makefile
config.status: creating tzpar/Makefile
config.status: creating util/print_resid/Makefile
config.status: executing depfiles commands

However, when I run the make, I get this:

Making all in src
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o a1ut1f.o a1ut1f.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o a1utcf.o a1utcf.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o ang.o ang.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o arrtim.o arrtim.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o atimfake.o atimfake.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bigendian.o bigendian.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o blkdbat.o blkdbat.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnrybt.o bnrybt.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnrybtx.o bnrybtx.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnrydd.o bnrydd.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryddgr.o bnryddgr.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryddk.o bnryddk.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryddt.o bnryddt.f
bnryddt.f:123:10:

   46 |         do 20 i=1,4
      |                        2
......
  123 | 20      trb(i)=-d2bar
      |               1
Warning: Array reference at (1) out of bounds (4 > 3) in loop beginning at (2)
bnryddt.f:123:19:

  123 | 20      trb(i)=-d2bar
      |                        ^
Warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
bnryddt.f:46:14:

   46 |         do 20 i=1,4
      |                     ^
note: within this loop
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryddfwhiecc.o bnryddfwhiecc.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryeh.o bnryeh.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnryell1.o bnryell1.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnrymss.o bnrymss.f
gfortran  -g -O2 -ffixed-form -ffixed-line-length-none -std=legacy -c -o bnrydds.o bnrydds.f
bnrydds.f:45:14:

   45 |         real*10 frb, tt0, tt, orbits
      |                     1
Error: Old-style type declaration REAL*10 not supported at (1)
make[1]: *** [bnrydds.o] Error 1
make: *** [all-recursive] Error 1

Any suggestion to solve this issue?

[paulray]

Surely this is because M2 doesn't support precisions higher than REAL*8 (double). It does not have long double support. I don't know what the solution is, other than top compile it on another machine that is x86_64 then copy it to your M2 machine and hope that it runs OK under Rosetta.

[scottransom]

Yup. Agree with @paulray