Make install cannot write to plugin directory

[gsjaardema]

Using main

When running make install, I get the following:

CMake Error at plugins/cmake_install.cmake:54 (file):
  file INSTALL cannot make directory "/usr/local/hdf5/lib/plugin": No such
  file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:94 (include)

This is using an HDF5 that I build and install in a non /usr/local/hdf5 area. However, in my HDF5 installs, I do not install any plugins, so I don't change the plugin directory from the default (Not sure why HDF5 build does not put the plugin directory path in my install path...)

Now, when I use that HDF5 library, netCDF tries to install its plugins into that same directory, but I don't have write access to that directory and it doesn't even exist...

The fix on my side is to probably specify the hdf5 plugin directory during the build of HDF5, but there is also an issue on netCDF side that if the plugin directory is not writeable by the person running the build, there will be a failure... Not sure of the correct fix, just reporting an issue...

[edwardhartnett]

This is the same as the case with the default install directory which is /use/local. If you are not using sudo you must specify both prefix and plugin dirs.

However most installs will use sudo.

This issue can be closed.

[gsjaardema]

The difference is that I am doing a complete build of both hdf5 and netcdf and specifying the install directories for both and out of the blue once I move up to the next version my builds break because there is now this default plugin directory.

I would think that if there is no HDF5 plugin directory specified, then the default plugin directory would be relative to the install location, not in a system location requiring sudo.

I disagree with "most installs will use sudo" since none of my users need to use sudo for any of the TPL.

I'm fine with closing the ticket since I have a workaround by specifying plugin directories for HDF5 even if I don't use them, but the current default doesn't seem right (But based on discussions I've seen; not sure any default is correct)

[gsjaardema]

I'm also a little confused as to why netCDF is installing files in my HDF5 plugin directory when my HDF5 library isn't using plugins... Are you expecting HDF5 to recognize this plugin at runtime when it didn't know about it at build time?

[DennisHeimbigner]

Are you expecting HDF5 to recognize this plugin at runtime when it didn't know about it at build time?

Yes, it will actually recognize them at run-time because if you attempt to read a file with compression, and no HDF5_PLUGIN_PATH is explicitly set, then it will search all the shared libraries in the default directory.

[edwardhartnett]

Installing plugins there is necessary for zstandard compression to work out of the box. Installing them elsewhere would mean most users could not read zstandard compresses data but would get a filter not found error when trying to.

It's not ideal but is the least worst default.

[DennisHeimbigner]

I would think that if there is no HDF5 plugin directory specified, then the default plugin directory would be relative to the install location, not in a system location requiring sudo.

Frankly we forgot this case. You can of course disable it by using --without-plugin-dir,
but as you say, your users (the same naive ones Ed talks about) will not know to do this
and will get a failure.
Ward -- is it too late for me to make a fix for this?

[edwardhartnett]

We did not forget this case, it is the very default case that we are primarily concerned about...

[DennisHeimbigner]

I would think that if there is no HDF5 plugin directory specified, then the default plugin directory would be relative to the install location, not in a system location requiring sudo.

As is clear from this thread, there is no perfect solution.
If you users are installing without sudo then does that mean they do not use compression
at all? Or do you tell them what HDF5_PLUGIN_PATH to use?

[DennisHeimbigner]

We did not forget this case, it is the very default case that we are primarily concerned about...

Sorry, but we did; we have been implicitly assuming that all installs occur using sudo.

[gsjaardema]

If you users are installing without sudo then does that mean they do not use compression

They use zlib (or zlib-ng) and sometimes szip; neither of which require the plugin directory. I am looking at supporting zstandard and zfp which will require plugin directories, but I then also need to make sure that the downstream application clients also support those plugins (e.g. commercial visualization codes...)

I guess I don't understand why you can't use compression if you don't use sudo... If I build my own HDF5 and specify the plugin directory, then I can use compression or other filters without requiring sudo.

[DennisHeimbigner]

IF you define the same HDF5_PLUGIN_PATH at both build time
and run-time, then the install will install into the directory
specified by HDF5_PLUGIN_PATH and everything works ok,
even without sudo (assuming that the installer has write access
to the HDF5_PLUGIN_PATH).

[edwardhartnett]

Alternatively use --with-plugin-dir to install the plugins wherever you want and have users set HDF5_PLUGIN_PATH to that directory.

[WardF]

@DennisHeimbigner it is not too late, do you think you can have it in today or tomorrow at the latest? This is the sort of situation I was worried about cropping up; while I understand the technical reasons for the decisions, it is going to lead to confusion insofar as the 'default' configure && make && make install command chain isn't going to work out of the box for people anymore. This doesn't necessarily require a lot of changes to what we're doing, but we need to make it more explicit. I'm going to also add a line in the libnetcdf.settings file. I'd really like to avoid a situation where we have to provide this information on a user-by-user basis, and when one of our power users comes here because the solution isn't immediately obvious, that signals to me we need to do a better job highlighting this information as part of the build process, if nothing else.

I don't want to get bogged down too much, we really, really need to get v4.9.0 out. But we can spare another day or so to clear up this sort of confusion.

[WardF]

(I'm also working to recover the Windows deployment environment VM I've been using; there's an issue I'm slogging through on my dev machine. So that gives us a day or so of breathing room to take a look at this.)

[DennisHeimbigner]

we have 3 choices, i think.

1. leave as is and deal with complaints by some fraction of users who install without sudo
2. change default back to --without-plugin-dir and deal with complaints of users who expect to use compressors out-of-the-box
3. change default to install into $PREFIX/hdf5/lib/plugin -- will take sometime to implement