The symptom is that autoconf based software that tries to link to libhdf5 fails
during the linking phase.  The configure script will succeed, find libhdf5, but
the build will fail with

"/usr/bin/x86_64-linux-gnu-ld.bfd: cannot find -lhdf5: No such file or
directory"

The work-around is to manually edit the Makefile in the directory with the
failing code, finding the line

HDF5_LDFLAGS =

and changing it to

HDF5_LDFLAGS = -L/usr/lib/x86_64-linux-gnu/hdf5/serial

or whatever is appropriate for the system.

The cause of this bug.  the AX_LIB_HDF5 macro in autoconf-archive runs "h5cc
-showconfig" to retrieve the CLFAGS, LDFLAGS, etc., for compiling software that
links to libhdf5.  It grep's for either H5_LDFLAGS or AM_LDFLAGS or both in the
output, I'm not sure which, and reports their value(s) in an autoconf variable.
There is a comment in the macro source code that one of the two is guaranteed
to be blank so the two values are combined blindly, but I can't find where it
actually does that, I can only find it grep'ing for H5_LDFLAGS, so that's why
I'm not sure what's going on, but that's immaterial because neither of them is
reporting the correct value.

h5cc reports both values to be blank.  However libhdf5.so from libhdf5-dev is
in /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so and so the correct LDFLAGS
is -L/usr/lib/x86_64-linux-gnu/hdf5/serial

I think h5cc needs to be modified to report -L/usr/lib/x86_64-linux-
gnu/hdf5/serial in one or other of its LDFLAGS variables.  Or libhdf5-dev needs
to be rebuilt with the .so put into the linker's default search path.  I've
assumed the bug is in h5cc, not the install path for libhdf5.so, that seems
deliberate, but the maintainers of these packages might shift the blame.

Since it doesn't report the correct linker flags to the user, it's possible
that h5cc is itself incapable of compiling libhdf5 based software.  I haven't
checked that.