@WardF @skosukhin can you review this PR?

ping @adamjstewart @WardF @skosukhin

@tkameyama thank you. A few more comments:

1. I am not sure that we need to build with MPI wrappers at all. netcdf-fortran, for example, uses mpi at least in the test suite and in the examples. Therefore, it makes sense to build it with MPI wrappers. netcdf-cxx4, on the other hand, does not seem to use mpi directly, the dependencies on MPI libraries are transitive and are supposed to be resolved implicitly via rpaths. The case of static linking does not seem to be properly covered anyway (at least I got linking errors when tried to build netcdf-cxx4 ^netcdf-c~mpi~shared). Could you, please, provide an example when we need to use MPI wrappers?

2. There is a problem with NEEDED entries in libnetcdf_c++4.so: underlinked libnetcdf_c++4.so.1: undefined symbol: nc_* Unidata/netcdf-cxx4#86. Basically, we can't simply link to the library: g++ main.c -L/some/path -lnetcdf_c++4. Instead, we always have to append -lnetcdf to the command. We can solve this in Spack. We can either:

   config_args.append('LIBS=-lnetcdf')

   or wait until autotools: set 'ldlibs' as 'LIBS' #17254 is merged and extend flag_handler with:

   elif name == 'ldlibs':
       flags.append('-lnetcdf')

   Could you, please, take care of this? In any case, it makes sense to add the link to the issue as a comment: the issue might get resolved upstream in the future and the workaround might become redundant.

3. Currently, the package unconditionally depends on automake, autoconf, libtool, and m4. This is because we have force_autoreconf = True, which was introduced ages ago. Could you, please, check whether we need this for the newer version (I would simply remove it).

Of course, it's fine if you say no to any of this. I just thought that since you seem to be interested in the package, you might want to fix some other issues as well.

1. I am not sure that we need to build with MPI wrappers at all. netcdf-fortran, for example,
   uses mpi at least in the test suite and in the examples. Therefore, it makes sense to build it with
   MPI wrappers. netcdf-cxx4, on the other hand, does not seem to use mpi directly, the dependencies
   on MPI libraries are transitive and are supposed to be resolved implicitly via rpaths. The case of static
   linking does not seem to be properly covered anyway (at least I got linking errors when tried to build netcdf-cxx4 ^netcdf-c~mpi~shared). Could you, please, provide an example when we need to use MPI wrappers?

I faild to compile plugins/H5Zbzip2.c.
H5Zbzip2.c include hdf5.h, and hdf5.h include mpi.h when hdf5+mpi.
(And I use Fujitsu MPI, and this package's header information is incorrect. #17253)
I restore mpi wrapper condition to dependency baseed.

2. There is a problem with NEEDED entries in libnetcdf_c++4.so:
   Unidata/netcdf-cxx4#86.
   Basically, we can't simply link to the library: g++ main.c -L/some/path -lnetcdf_c++4.
   Instead, we always have to append -lnetcdf to the command. We can solve this in Spack.

I think it's better to solve this problem by adding -lnetcdf to LIBS in the configure script.
I add patch for this.

3. Currently, the package unconditionally depends on `automake`, `autoconf`, `libtool`, and `m4`. This is because we have `force_autoreconf = True`, which was introduced ages ago. Could you, please, check whether we need this for the newer version (I would simply remove it).

Maybe we still need it.

@skosukhin

2. There is a problem with NEEDED entries in libnetcdf_c++4.so: Unidata/netcdf-cxx4#86. Basically, we can't simply link to the library: g++ main.c -L/some/path -lnetcdf_c++4. Instead, we always have to append -lnetcdf to the command. We can solve this in Spack.

I understand this problem.

Nomally, If we want too use libnetcdf, we use AC_SEARCH_LIBS in configure.ac.
AC_SEARCH_LIBS([nc_create], [netcdf], [], [])
AC_SEARCH_LIBS search libnetcdf and add -lnetcdf to LIBS variable.

But currently when nc-config is found, configure.ac skip AC_SEARCH_LIBS, and LIBS variable is not updated.

libnetcdf_so.4.3.1.patch append output of nc-config --libs in LIBS variable.

@skosukhin @tkameyama Is this something we still want or can we close the PR?

Closing this PR as stale, but feel free to reopen if you want to continue working on it.