Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build NetCDF using ./configure and create only static libs #52

Merged
merged 19 commits into from
Jul 8, 2020
Merged

Build NetCDF using ./configure and create only static libs #52

merged 19 commits into from
Jul 8, 2020

Conversation

kgerheiser
Copy link
Contributor

I configure some scripts and run ./configure to build NetCDF, creating only static libs (including HDF5 and zlib).

Copy link
Collaborator

@climbfuji climbfuji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably beyond this PR: regarding zlib, we always had the issue that zlib is a dependency for libpng as well and that we need to use the same for both. By only using static libraries, we can already avoid the problem that at runtime the wrong library is picked. So now we need to make sure that building netcdf and png always have to go together (build both or none), or find a better solution. What if png is available and built against a shared zlib that we cannot use for netcdf in nceplibs-external? Something to discuss.

CMakeLists.txt Outdated Show resolved Hide resolved
config_netcdfc.sh.tmpl Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
@kgerheiser
Copy link
Contributor Author

kgerheiser commented Jul 2, 2020

Fixed and run make check/test (this does significantly increase the build time). Maybe I should add it as a separate step?

@kgerheiser
Copy link
Contributor Author

kgerheiser commented Jul 2, 2020

Do you know about building HDF5? Why do we set the compilers as MPI_<lang>_COMPILER but we don't install with parallel support? Shouldn't we just use CMAKE_C_COMPILER etc instead?

We set MPI_CXX_COMPILER, but building with parallel is not supported with building C++ support and make test will fail on the C++ test. So, I turned off C++ bindings. The alternative is to set the non-parallel compilers.

@climbfuji
Copy link
Collaborator

Do you know about building HDF5? Why do we set the compilers as MPI_<lang>_COMPILER but we don't install with parallel support? Shouldn't we just use CMAKE_C_COMPILER etc instead?

We set MPI_CXX_COMPILER, but building with parallel is not supported with building C++ support and make test will fail on the C++ test. So, I turned off C++ bindings. The alternative is to set the non-parallel compilers.

I think we never bothered building the parallel version, because the UFS didn't need it. Since it's coming in the UFS weather model, we should probably enable the parallel builds of hdf5 and netcdf. No need for C++ bindings I suppose.

@climbfuji
Copy link
Collaborator

Please do not delete .github/workflows/macos-gccgfortran.yml - we want to test on both Linux and macOS. We can do Linux with gcc+gfortran and macOS with clang+gfortran. I can fix the macOS action after your PR, if needed.

@kgerheiser
Copy link
Contributor Author

kgerheiser commented Jul 7, 2020

I'm not actually deleting it. I just can't get either one to work. Mac because its using GCC10 and this version of NetCDF-Fortran has errors building with GCC 10. Linux because NetCDF-Fortran can't find NetCDF-C even though it builds fine on my Mac and on Orion.

@climbfuji
Copy link
Collaborator

climbfuji commented Jul 7, 2020 via email

@kgerheiser
Copy link
Contributor Author

If you would. I can't see anything that's wrong and it builds everywhere I try that isn't Github.

@climbfuji
Copy link
Collaborator

climbfuji commented Jul 7, 2020 via email

@kgerheiser
Copy link
Contributor Author

I was able to reproduce the Linux error on an Ubuntu server I have

@kgerheiser
Copy link
Contributor Author

Think I found the problem. I added -lm and -ldl to LIBS of NetCDF-Fortran because it was getting undefined references to these libraries. They were linked but not in the right order. -lm -ldhf5 is wrong but -lhdf5 -lm is fine. I don't know it works on other OS`s though.

@kgerheiser
Copy link
Contributor Author

Looks like it's working. zlib, HDF5, NetCDF, and ESMF build and all tests pass.

@climbfuji
Copy link
Collaborator

Looks like it's working. zlib, HDF5, NetCDF, and ESMF build and all tests pass.

That's awesome, I'll test your PR on my Mac as well. You are still deleting the macos travis file, can you please put it back? I'll fix that failed test later.

@kgerheiser
Copy link
Contributor Author

kgerheiser commented Jul 8, 2020

Ok, just gotta use GCC-9 for Mac and it should work

@climbfuji
Copy link
Collaborator

Ok, just gotta use GCC-9 for Mac and it should work

Thanks, will do. Good to know - and we should note that in the release notes for MRW App 1.1 - that GNU 10 won't work.

@kgerheiser
Copy link
Contributor Author

See here

Unidata/netcdf-fortran#212

@kgerheiser
Copy link
Contributor Author

I will merge this and then I can add the new wgrib2

@kgerheiser kgerheiser merged commit ffd3f1f into NOAA-EMC:develop Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants