Silo's autogen script cannot find the hdf5 library when hdf5 is built in Debug mode using CMake

[Algiane]

Hello,

Thank you for providing the Silo library.

I have issue to build the release 4.11 of Silo with hdf5 capabilities when hdf5 is built in Debug mode using CMake: in this case, CMake appends the _debug postfix to the library name (so the produced library is named libhdf5_debug.[ so | dylib | a ...].

As the configure script of Silo searches for the hdf5 library, hdf5 is not founded and the build fails.

Additional informations:

• I can reproduce this issue:

  • on my Mac M1, with CMake 3.26.3;
  • on an Ubuntu 22.04 Docker image with CMake 3.22.1;

• I am using the release 1.12.1 of hdf5 but I can reproduce the issue with other versions;

• Building hdf5 using Autogen works as the library is always named libhdf5;

• Building hdf5 with CMake in other modes than the Debug one (RelWithDebInfo, Release, ...) works too (for the same reason, the library is named libhdf5);

• using the CMake build of the main branch of Silo solves the link issue but I would prefer to stick with a stable version of Silo.

Questions

• Have you already planned the next release of Silo ?
• In the meantime, is it possible to add a way to provide the hdf5 library name to Autogen (using the $LIBS variable is not safe as a user can have 2 coexisting versions of the hdf5 library (a Debug version and another one and the hard coded -lhdf5 will find the unwanted version)?

Thank you by advance for your help,
Best

[markcmiller86]

I believe our transition to full CMake builds is not quite complete.

Is there any chance you can use the AutoTools build instead?

Regarding libhdf5.so vs libhdf5_debug.so (or whatever extension you have), that seems like an issue either in HDF5's CMake logic or in the way the HDF5 library was configured using CMake (or Autotools) as there is no reason it should be changing the name of the built/installed library.

If you have installed HDF5 yourself, can you create symlinks in the HDF5 install point to make a libhdf5.so that points to the libhdf5_debug.so?

Silo's Autotools build allows for hdf5.h and libhdf5.so to be in totally unrelated dirs but it does not allow for an HDF5 library file to be named anything other than libhdf5.so (or whatever extension you are using).

[Algiane]

Hello,

Thanks for your feedback.

I think that the use of a debug postfix in the library name is pretty standard with CMake because it allow to build both Release and Debug versions of a library into the same install directory and to package both versions using CPack (see the CMake documentation here or here or this discussion that is related to the use of a debug postfix into library names).

I have seen lot of projects that are using this convention (for example VTK, curl or vcpkg) so I have no hope that the hdf5 developpers will change this feature for me ;-).

The idea of a symbolic link isn't really feasible because it may break up the user's hdf5 installations (Release builds have already the libhdf5.so name and the debug postfix is here to allow to have both versions of libhdf5.so and libhdf5_debug.so in the same directory).

Best

[markcmiller86]

see the CMake documentation here or here or this discussion that is related to the use of a debug postfix into library names

Well, there are other approaches to handling that including installing a debug version of the library at a different path as in /usr/local/lib/debug/libhdf5.so. The fact that VTK follows the same practice is not too surprising as both CMake and VTK are developed by KitWare.

And, one reference you mention is aimed at trying to install the same library in the same install point but with different features....in this case debugging enabled or not. But, why stop at debugging though? Why not install the same library but different versions or for different CPU architectures or with MPI enabled or how about combinations (MPI without debugging and MPI with debugging) etc. In all cases I have experience with, these are all handled by installing the same libxxx.so to a different install point, not changing the name of the installed library.

I believe this is how Spack operates when it installs different variants of the same library...different install points not differently named installed packages.

Now, as it turns out, the Silo library kinda sorta does install differently named packages. But, its install logic has always done this. From the first time HDF5 was introduced, Silo installs libsilo.so (without HDF5) and libsiloh5.so (with HDF5) to the same install point. But that is because we made a choice at the time HDF5 was introduced to Silo to name the installed Silo library with HDF5 siloh5 and not silo. This has in fact lead to issues for users maintaining make files that build with either silo installation. That is a different situation IMHO because, as I mention, Silo with HDF5 was chosen to be named siloh5, a differently named installed package.

[markcmiller86]

Also, quoting from the first ref you offer,...

By default, CMake's model is that a build directory only contains a single configuration, be it Debug, Release, MinSizeRel, or RelWithDebInfo.

[Algiane]

I understand: honnestly I have no opinion on the library naming convention (I am not expert in compilation, installation or packaging), I just wanted to point out that the postifx inside the hdf5 library name is not an error from the hdf5 developpers but a conscious choice. In consequence, it's unlikely that they'll rename their library if I open an issue.

On the other hand, current Silo's Autotools fail to find hdf5 library if it is build in Debug mode with CMake:
hdf5 is unlikely to change their library name so if you are interested to maintain a full compatibility between hdf5 and Silo (it may not be the case), I think that it has to be done from the Silo side.

On another note, I agree that:

• At least for my own usage, I don't need this _debug postfix;
• I have always managed installations of different configurations using different directories (but I work mainly on unix systems, I am not able to extrapolate on others)
• It is probably hard to handle this inside Autotools;

Anyways, from my side, it's a sticking point for compiling the TPLs for one of the projects I'm working on:

• This project, GEOS, has lot of dependencies (ThirPartyLibraries);
• Due to some non-compatibilities between autogen and CMake, I am forced to build hdf5 with CMake (the release build of hdf5 using autogen propagates a spurious NDEBUG preprocessor flag to CMake, which disables the assertions inside Geos in Debug mode, see this PR);
• The user may want to build the TPLs (the hdf5 library among others) in Debug mode;
• I have not yet found a workaround to fix the Silo build in this case (I have tried to undefine the CMAKE_DEBUG_POSTFIX variable and to define it to and empty string with no success);
• The idea of the symlink may be a solution but it is a bit dirty an I am not sure of the side effects (for example for a user who choose to build the TPLs in Debug mode, with an installation in the system PATH and with an already existing installation of hdf5 in Release mode...).

I hope to convince you that fixing this compatibility issue is in the interests of your user community (;-)).
Do not hesitate to close this ticket if you think that it is useless to fix this.

Thanks again for you answers,
Best