libhdf4 fails to cross build from source for multiple reasons. When not
building for armhf, the failure is selecting a build architecture
compiler. This is due to the upstream build system using its own
compiler detection rather than relying on the one provided by autoconf.
I am aware that you mentioned switching to CMake, but it seems like
exporting suitable CC+CXX would still be a worthwhile change in the mean
time. You can drop that once switching to CMake.

When it comes to armhf, the use of gcc-14 is implemented in a way
breaking cross builds. Toolchain build dependencies should be annotated
with -for-build or -for-host (depending on what is appropriate). The
conditional in debian/rules branches on the build architecture when it
should be branching on the host architecture and the assigned compilers
fail to account for the triplet. All of these changes apply beyond the
switch to CMake.

Once fixing these, the next build failure arises from running the built
ncgen. I am not familiar with this tool, but it ends up getting
installed into hdf4-tools, which is marked as Multi-Arch: foreign. This
suggests that we should likely be using the installed version for cross
builds only. Do you concur here?

In any case, I think we should defer the surgery about ncgen until after
the migration to CMake has proceeded. This bug report is not meant to
cover the ncgen aspect.

Helmut

Thanks for the patch, it's applied in git.

To be honest, I'm not sure. I'm very far from fluent in cross-building.

The package contains a mix of scripts and binary executables, the latter should use the libhdf4-0 from the same architecture.

At least ncgen is executed as part of the test suite which suggests you need the installed version for cross builds if I understand cross-building correctly, or nocheck.

You should definitely try to spend as little time on this package as possible.

HDF4 is legacy software, upstream has its focus on HDF5. I only maintain the package because it's a dependency of gdal, I don't actually use it myself.

There is still HDF4 data out there, and people having a need for libhdf4 as proven by Antonio Valentino's work on python-hdf4 which is used by his remote-sensing related packages.

As a non-user of hdf4 I'm not sure about the value of the hdf4 variants of the tools also provided by netcdf like ncgen, I suspect users need those because netcdf is based on hdf5 so its tools only work those newer formats.

I suspect your work on hdf4 is to make (re)bootstrapping the key package set possible in which hdf4 finds itself thanks to gdal/opencv/ffmpeg, the opencv dependency is a bit unfortunate because it makes gdal a much more significant package then it deserves to be. GDAL is one of the core libraries in the geospatial world, but in the wider Linux world it most definitely is not.

Kind Regards,

Bas