NOAA-EMC / NCEPLIBS-external

Third-party libraries required by NCEPLIBS
Other
8 stars 16 forks source link

develop branch fails to build netcdf-c on MacOS #92

Open mkavulich opened 3 years ago

mkavulich commented 3 years ago

I have been doing regular tests on the release/public-v2 branch on MacOS with GNU 9 and 10 compilers for the past few months, and these have been successful. However, now that I am trying out the develop branch, I am running into problems with the build.

The issue appears to be related to the netcdf-c configuration and the naming conventions of compilers on my machine. I have installed several versions of the GNU compilers using Homebrew on my machine, and the default naming scheme for these is [compiler]-[majorversion]; e.g., gcc-9, gfortran-9, etc. For this example, I have set the following environment variables prior to the build:

CC=gcc-9
FC=gfortran-9
CXX=g++-9
CMAKE_C_COMPILER=gcc-9
CMAKE_Fortran_COMPILER=gfortran-9

The relevant portion of the make log seems to indicate that the C compiler flags are not being properly passed to the netcdf-c build, and so it is testing "gcc" which is an older gcc version rather than testing "gcc-9" as one would expect:

checking for gcc... gcc
checking whether the C compiler works...   CC       src/thread/mpl_thread_win.lo
yes
checking for C compiler default output file name... a.out
checking for suffix of executables...   CC       src/thread/mpl_thread_solaris.lo
  CC       src/thread/mpl_thread_argobots.lo

checking whether we are cross compiling... configure: error: in `/Volumes/d1/workdir/UFS/workdir_gnu9/NCEPLIBS-ufs-develop-2020-03-05/src/NCEPLIBS-external/build/netcdf-c':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[2]: *** [netcdf-c/src/netcdf-stamp/netcdf-configure] Error 1
make[1]: *** [CMakeFiles/netcdf.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

A number of other components properly recognize the correct specified compilers prior to this failure (correctly identifying the C compiler as gcc-9), and as I mentioned, the release/public-v2 branch compiles correctly with these same flags/variables. I am not sure what exact difference between the release/public-v2 branch and develop is causing this difference in behavior, so I am hoping someone more experienced with the cmake build and submodules can help. The full cmake and make logs are linked here: cmake.log make.log

I don't believe this is related to #85 but I can't tell for sure because the referenced testing logs have expired.

*Edited for format which hid an important line in log message