Status of cmake build setup

[nncarlson]

Having successfully built and installed the latest (4.4.0) netCDF C libraries using cmake, I'm trying to do the same for the Fortran libraries. I was expecting to find some cmake variable that I could point at the installed netCDF cmake configuration files, but didn't. I also see a find_package(netCDF) command but no corresponding FindnetCDF.cmake file in either the standard cmake installation or in the source tree for netcdf-fortran. So I'd guess that the cmake build isn't really quite there yet? Is there a way to point it to the netCDF installation?

[WardF]

If you've built netCDF-C with cmake, there should be a folder in the install location along the lines of $(CMAKE_INSTALL_PREFIX)/lib/cmake/netCDF/. This directory contains the following:

• netCDFConfig.cmake
• netCDFConfigVersion.cmake
• netCDFTargets-debug.cmake
• netCDFTargets.cmake

For cases where netCDF-C was not built by cmake, or if the files I mentioned above are missing, the CMakeLists.txt will still find the netCDF-C libraries; rather, it should. In the case where I've installed libnetcdf in a custom location, I would invoke cmake for netCDF-Fortran as follows:

$ cmake [path to netcdf-fortran source directory] -DCMAKE_PREFIX_PATH=/home/wfisher/Desktop/local

In this example, libnetcdf was built with either -DCMAKE_INSTALL_PREFIX=/home/wfisher/Desktop/local or --prefix=/home/wfisher/Desktop/local

It may be that the cmake-specific variable you are looking for is CMAKE_PREFIX_PATH; it's not netCDF-C specific, but it should work. Are you observing an issue when using this?

[nncarlson]

Yep, CMAKE_PREFIX_PATH is the thing I was after, but not using -- thanks! Things work fine now, except with the NAG compiler, but that's a different issue...

That compiler won't accept link line shared libraries that have the version suffix (libnetcdf.so.11.0.0, for example), complaining about an "unrecognized file suffix". That, unfortunately, is what the installed netcdf cmake files are serving up, and even later netcdf-fortran wants to use for the netcdff library when linking test programs. Do you why things want to use the versioned lib file names instead of the plain .so symlink? Curiously, find_library will return the latter.

All this can be hacked around easily enough for a one-off build, but I'm trying to put together something completely automatic for a TPL superbuild for another package, so I'm a little stymied.

[WardF]

I'm glad CMAKE_PREFIX_PATH worked!

I'm not familiar with the NAG compiler; that is odd that it doesn't like the versioned shared library. I've been playing around with this a bit today, but I can't find a way to suppress the version suffix on the current version of netCDF.

I see how we could accommodate this with an advanced cmake option (DISABLE_SHARED_VERSION_SUFFIX or some such), but that doesn't really help you right now. Maybe there's a way to overcome this with the NAG compiler; have you contacted their support? It's a longshot, but I'm a bit at a loss. Building with configure results in the same behavior.

Unfortunately I don't know enough about the linker to even guess why it's taking the file instead of the simlink, unless it is taking the simlink and then following/resolving it to the actual file.

I think the best bet on our end for a permanent resolution would be to add an option as mentioned above that would skip associating an SO version with the shared library. An automated solution until then would revolve around the CMakeLists SET_TARGET_PROPERTIES command in liblib/CMakeLists.txt, around line 97; maybe delete or comment it out with sed? Anyways, I'm going to open an issue for the shared version suffix, and will add a link to it here once it's been created.

[WardF]

Opened issues for this in netCDF-C and netCDF-Fortran:

• Allow for creation of unversioned shared libraries in cmake netcdf-c#228
• Allow for creation of unversioned shared libraries in cmake #45

[nncarlson]

@WardF. Added a comment to Unidata/netcdf-c#228. To answer your questions above: yes, I've pinged the NAG support about this. Their screening of command line arguments based on file suffix isn't being helpful. And just to be clear, the issue isn't that the linker is substituting one file for another; it is being told to use the versioned file, and that is coming from cmake. My gut feeling is that cmake shouldn't be doing that. I've also posted a query to the cmake mailing list, but no response yet.

[WardF]

What happens if you try building with autotools, e.g. configure? Do we see the same behavior? This would help determine if it's cmake-specific.

[nncarlson]

@WardF, I've pretty much nailed down that this is a problem in the NAG compiler. It has no problems handling versioned shared library path names as link arguments, but only if there are no more than 2 fields in the version. So libnetcdf.so.11.0 would be okay but libnetcdf.so.11.0.0 is not. It's clearly a limitation in some unnecessary argument checking that they are doing; it seems unrelated to the choice of soname embedded in the file as far as I can tell from my testing.

Your proposed option to dispense with versioning would workaround this problem, but I wouldn't bother unless it was really easy and didn't muck up the cmake and autoconf files too much (this problem is unrelated to cmake or autoconf). I've reported the problem to NAG. Thanks for the interest you've shown; I'm not sure I would have done the same if I were in your place!

[WardF]

I've added an option to cmake-based builds under netcdf-c that will allow you to build unversioned libraries. The new option is ENABLE_SHARED_LIBRARY_VERSION, and is ON by default. I'm planning on doing the same for netcdf-fortran. It's not a problem at all, and I suspect most people won't ever notice the option is there, but it is innocuous enough that I don't mind doing it.

I'm glad you were able to nail down the issue to the NAG compiler, insofar as it's not a netcdf issue, and I hope it's something you're able to work around. I'm going to close out this issue, feel free to follow along with #45 for status. I'm focusing on a release of netcdf-cxx4 right now, and then the C/Fortran releases.