Ward Fisher

Wow this has really lingered. My sincere, embarrassed apologies. @K20shores this feels like something that might fit in with the work we're doing over at #2847?

Thanks to the renewed interest, some additional info/reading provided by @dopplershift, and an expanded knowledge of `-fsanitize`, I think we have a fix for this. It also looks like we...

Merged in with #2826

I am trying to get some issues closed, and I am curious if this is still occurring with version `v4.6.0`, or if people are still using `v4.5.4`.

Thank you, this is interesting. This has long been a frustrating issue, as it hasn't been something I can directly recreate. Out of curiosity, @mjs271 do you *have* an older...

Thanks @mjs271 ! Interesting, looking at why this is failing, I see that the check message is dependant on `nc_def_var_szip` being found in `libnetcdf`. Do you have access to the...

So it appears that this is the culprit; without szip support, the function that netCDF-Fortran checks for is absent, and thus netCDF-Fortran responds with a misleading issue. This needs to...

So I'm running into a wrinkle here; while the conclusion drawn from this conversation makes sense, it's not what I'm observing in my own local install. Even when `libhdf5` was...

Thanks; it is good to know that it works in `configure`-based builds, which narrows down many of the issues. Particularly since `nc_def_var_szip` is absolutely present in `libnetcdf.so`, so the check...

Ok, I think I've found something. I was able to replicate this issue by using **static** `libnetcdf` and `libhdf5` libraries, instead of shared. The failure comes from *all* `check_library_exists()` invocations...