You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.logmake.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
The text was updated successfully, but these errors were encountered:
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:
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:
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
The text was updated successfully, but these errors were encountered: