Add support for Apple arm64

[MicroTed]

This provides fixes for compiling on Apple M processors for anybody who is interested. The libraries work for linking/running Fortran programs. Ncl seg fault on contour plots is also fixed.
Note: compiled/tested without grib, hdf4, hdfeos5 -- just netcdf4.

Build setup:
Macos 12.6 (Monterey)
Xcode 13.4.1
gcc/gfortran 12.2 (via homebrew)
XQuartz 2.8.1
Homebrew (for almost all library dependencies; note must use proj@7 as it fails with 8+)
netcdf-4.9.0 (w/ hdf5)

For Ventura:
Xcode 14.3.1
gcc-12/gfortran-12 (probably would work also with v11 or 13, but not tested)
XQuartz 2.8.5

Probably could use macports libraries to do a full build (i.e., support grib etc.), but I haven't tried that yet.

[MicroTed]

Ncl is working!!! I found that one point of failure is in cpnumb.f when called from C (Format.c). It is not getting a correct length of cbuf, and len(cbuf) returns a large value like 5091688. That causes an out of bounds for statements

  CBUF=' '

and

 CBUF='0'

Since Format.c uses a size of 128 for cbuf, I added a hack to check if the size of cbuf is "large" then set lbuf=128. (And also change cbuf=' ' to cbuf(1:lbuf)=' ').

A better fix may be to go through and add an explicit length to the call interface. I don't know much about calling Fortran routines from C, so there might be an easy fix on that end?

I have only tested a couple scripts, but so far, so good.

[MicroTed]

The root of the string length problem seems to be that the C code needs to declare the length variables as 'long int' (8 byte) instead of 'int' (4 byte) on the arm64 architecture. An update to Format.c does this for -Darm64 (and change to yMakefile to add the ARCH_DEF flags to the compile options).

Edit: removed arm64 switch and simply declare the variables as 'long'

[rjdbcm]

Small issue: inline BOZ literals aren't supported on some host [GNU] compilers.

C
C     ...
C
      parameter (ARGBMASK  = int(Z'40000000'))
      parameter (RMASK     = int(Z'00FF0000'))
      parameter (GMASK     = int(Z'0000FF00'))
      parameter (BMASK     = int(Z'000000FF'))
C
C     ...
C

Solution: In newer Fortran I believe that most non-GNU compilers will accept explicit DATA declaration of BOZ literals.

C
C     ...
C
      INTEGER  AM,RM,GM,BM
      DATA AM /Z'40000000'/
      DATA RM /Z'00FF0000'/
      DATA GM /Z'0000FF00'/
      DATA BM /Z'000000FF'/
      PARAMETER(ARGBMASK=AM),(RMASK=RM),(GMASK=GM),(BMASK=BM)
C
C     ...
C

[MicroTed]

@rjdbcm I tested the suggested change, but it doesn't like setting a parameter from a nonparameter:

gfortran-12 -fPIC -fno-range-check -Wall -fallow-argument-mismatch -fallow-invalid-boz -O  -g    -c -o argb2ci.o argb2ci.f
argb2ci.f:24:25:

   24 |       PARAMETER(ARGBMASK=AM),(RMASK=RM),(GMASK=GM),(BMASK=BM)
      |                         1
Error: Parameter 'am' at (1) has not been declared or is a variable, which does not reduce to a constant expression

I suppose a work-around would be to not declare the mask variables as parameters, but that seems risky.

By the way, adding the int function to the declaration (e.g., int(Z'40000000') ) allows it to compile without the -fallow-invalid-boz option. I suppose that any compiler that doesn't like the current version probably didn't like the original, either?

[MicroTed]

Latest update removes wrf_constants.mod from the object list in ni/src/lib/nfpfort/yMakefile because a newer version of ld throws an error (macos ventura, xcode 14.3.1). The library shouldn't need .mod files, anyway (it has the .o file), since .mod file are only used for compiling the other .o files.

@ Dave-Allured does anybody review PRs for ncarg any more, or is it pretty much frozen at this point?

[Dave-Allured]

This last commit "Removed wrf_constants.mod" is a duplicate of #192. Either remove it here, or be careful later, when merging both.

[MicroTed]

This last commit "Removed wrf_constants.mod" is a duplicate of #192. Either remove it here, or be careful later, when merging both.

Ah, I hadn't seen that PR from @tenomoto -- thanks for pointing it out. I suppose I can remove it after that PR is approved and merge that in. Just so that this branch compiles correctly in the meantime. Or the PRs could be combined -- whatever works best.

[Dave-Allured]

does anybody review PRs for ncarg any more, or is it pretty much frozen at this point?

I can't speak for NCAR, but I do not think it is officially frozen for maintenance. I suggest continue to submit issues and PR's when you like. There is patch activity at conda-forge and macports, but this NCAR/ncl repo has continuing value as a central knowledge area.

[ryandesign]

Don't disable the implicit function declaration error. This condition was made an error for a reason. It is important to fix it properly by declaring all functions before you use them.

[MicroTed]

I believe it used to be OK to have implicit declarations, but more recent compilers have started treating these as errors. I'm not the one to fix all those, and if I recall there are a lot of them.