V4.9.0

[ocefpaf]

Closes #139

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ocefpaf]

Linux is failing with:

/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJreclaim':
ncjson.c:(.text.NCJreclaim+0x0): multiple definition of `NCJreclaim'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJreclaim+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJnew':
ncjson.c:(.text.NCJnew+0x0): multiple definition of `NCJnew'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJnew+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJnewstringn':
ncjson.c:(.text.NCJnewstringn+0x0): multiple definition of `NCJnewstringn'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJnewstringn+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJnewstring':
ncjson.c:(.text.NCJnewstring+0x0): multiple definition of `NCJnewstring'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJnewstring+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJparse':
ncjson.c:(.text.NCJparse+0x0): multiple definition of `NCJparse'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJparse+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJdictget':
ncjson.c:(.text.NCJdictget+0x0): multiple definition of `NCJdictget'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJdictget+0x0): first defined here
/home/conda/feedstock_root/build_artifacts/libnetcdf_1655124967558/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: ../liblib/libnetcdf.a(ncjson.c.o): in function `NCJcvt':
ncjson.c:(.text.NCJcvt+0x0): multiple definition of `NCJcvt'; CMakeFiles/nczhdf5filters.dir/NCZhdf5filters.c.o:NCZhdf5filters.c:(.text.NCJcvt+0x0): first defined here
[ 32%] Building C object plugins/CMakeFiles/nczstdfilters.dir/NCZstdfilters.c.o
collect2: error: ld returned 1 exit status
make[2]: *** [plugins/CMakeFiles/nczhdf5filters.dir/build.make:118: plugins/lib__nczhdf5filters.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:2820: plugins/CMakeFiles/nczhdf5filters.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 32%] Linking CXX shared module lib__nczstdfilters.so
[ 32%] Built target nczstdfilters
make: *** [Makefile:166: all] Error 2

[dopplershift]

cc @WardF @DennisHeimbigner

[WardF]

I'll take a look to see how to duplicate and then fix this, and will round out our CI as needed; this isn't occurring on our end as-is. Thanks.

[ocefpaf]

I'll take a look to see how to duplicate and then fix this, and will round out our CI as needed; this isn't occurring on our end as-is. Thanks.

BTW, what version of zstd are you using in your CIs?

[DennisHeimbigner]

The json code occurs twice in our code base: once for use by plugins exclusively
and once for all the rest of the code. I suspect you are accidentally including both versions.
Note that the plugin version is constructed in the makefile from the other version.
If my speculation is correct, I will need to rethink how I build the json code.

[WardF]

I'll take a look to see how to duplicate and then fix this, and will round out our CI as needed; this isn't occurring on our end as-is. Thanks.

BTW, what version of zstd are you using in your CIs?

The version being installed by the underlying package manager, so let me see if I can extract that information.

[kmuehlbauer]

@WardF @DennisHeimbigner Did you had any time to look into this?

[kmuehlbauer]

OK, after a bit of digging this is already in the works somehow: Unidata/netcdf-c#2419

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• pin_compatible should be used instead of pin_subpackage for libnetcdf because it is not a known output of this recipe: ['libnetcdf'].

[kmuehlbauer]

@ocefpaf I've added a patch for this to the PR branch. Let's see if this works.

[kmuehlbauer]

Hmm, the created patch fails to apply...

[kmuehlbauer]

Maybe it wasn't worth the try. Hopefully 4.9.1 is out anytime soon.

[WardF]

It looks like this is passing and ready for somebody else to review and merge. Thanks all!

[ocefpaf]

Thanks @WardF! Indeed it looks like a task that only someone with more intimated knowledge of the source code could fix. While I'm OK merging this, there is a lot of patching and I wonder if it makes sense to wait for a new release in case that is happening soon.

[WardF]

@ocefpaf I wanted to have one out by the end of the month, and that could still happen; if it's not out this week, I'm going to try to have it out next week. This was the largest blocking issue to resolve, but I still have some documentation to add and/or revamp, among all the other sundy day-to-day items we all deal with XD. I don't have any particular insight into the workflow and/or implications of skipping this version in libnetcdf-feedstock, however, so I'll leave that for a broader group discussion :)

[xylar]

@WardF and @ocefpaf, can I push a commit to remove static library builds? It seems like everything else i in place.

[xylar]

Sorry, just getting caught up on the conversation. It sounds like it doesn't make sense to push anymore changes to the branch until we know if we're merging this or waiting for 4.9.1.

[WardF]

Having thought about it, I believe this should be merged; I'll also ensure the patches contained in this (and, moving forward, other) PR's find their way back upstream into the netcdf-c repo.

[dopplershift]

With the exception of the ncjson patch (taken from upstream), all the patches added here tweak CMake/a few tests (and associated build files), so I'm comfortable that what we have here is fine and would be comfortable merging.

@xylar do you want to make the changes to eliminate the static build?

[xylar]

Thanks, @hmaarrfk! Those are almost exactly the commits I had staged. Except that I didn't think to check that the static library is not there, which is excellent!

[hmaarrfk]

I think i got it, removing the static.

[xylar]

Assuming CI passes, I'm very happy to see this merged.

[dopplershift]

With all that said, we probably want to wait for the (soon-to-be-released) 4.9.1 to think about migrating downstream compiled packages.

[xylar]

@dopplershift, I think that probably makes sense. Have this version available but not migrate to it?

[dopplershift]

@xylar Yeah. We can always decide to migrate if for some reason 4.9.1 becomes delayed, but that shouldn't be the case. No need to do two migrations in rapid succession, but having it available can also allow for some more testing by interested users.

[xylar]

Who dares hit the green button?