gdal-2.3.1_0+hdf5+netcdf+postgresql95 fails to build

[EJFielding (Eric Fielding)]

I recently updated several ports to be +openmpi, which triggered rebuilding of gdal among other ports. The rebuild failed because it is not finding the "mpi.h" header reference in the hdf5.h (hdf5 was installed with +openmpi). Here is the part of the log file that I assume is relevant (full log attached).

...
:info:build /bin/sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/libtool --mode=compile --silent --tag=CXX /usr/bin/clang++ -std=c++14 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/port -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/gcore -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/alg -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/ogr -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/ogr/ogrsf_frmts -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/gnm -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/apps -DHAVE_AVX_AT_COMPILE_TIME -DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME -pipe -DGDAL_COMPILATION -stdlib=libc++ -arch x86_64  -Wall -Wextra -Winit-self -Wunused-parameter -Wformat -Werror=format-security -Wno-format-nonliteral -Wshorten-64-to-32 -Wshadow -Werror=vla -Wdate-time -Wnull-dereference -Wextra-semi -Wcomma -Wfloat-conversion -Wdocumentation -Wno-documentation-deprecated-sync -Wunused-private-field -Wmissing-prototypes -Wmissing-declarations -Wnon-virtual-dtor -Woverloaded-virtual -fno-operator-names -Wimplicit-fallthrough  -DGNM_ENABLED -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_gdal/gdal/work/gdal-2.3.1/gdal/port  -DGDAL_COMPILATION -I/opt/local/include  -c -o ../o/gifdataset.lo gifdataset.cpp
:info:build In file included from hdf5dataset.cpp:42:
:info:build In file included from /opt/local/include/hdf5.h:22:
:info:build /opt/local/include/H5public.h:60:13: fatal error: 'mpi.h' file not found
:info:build #   include <mpi.h>
:info:build             ^~~~~~~
:info:build 1 error generated.
...

I have selected one of the openmpi port versions.

>>port select mpi
Available versions for mpi:
	none
	openmpi-gcc7-fortran
	openmpi-mp-fortran (active)

[EJFielding (Eric Fielding)]

main log

[Veence (Vincent)]

Hmmm… I’m not precisely keen on mpi, but mpi is tied to a particular compiler, right? So you can’t anything compile with mpi using clang, you have to use the selected version of your mpi compiler instead. Is that correct?

[mf2k (Frank Schima)]

The port selected with port select should never affect if a port can be built.

[Veence (Vincent)]

Replying to mf2k:

The port selected with port select should never affect if a port can be built.

However, the port should honor the mpi choice that was made, no?

[EJFielding (Eric Fielding)]

Maybe the responsibility here is for the openmpi port to add the appropriate mpi.h to /opt/local/include? I added the openmpi port to the ticket list. I faced the same issue when trying to build a package outside of MacPorts. I had to add "/opt/local/include/openmpi-gcc7" to the build include list because the package was including "hdf5.h" that then wanted "mpi.h".

[mf2k (Frank Schima)]

Whatever it needs to honor needs to be based on installed versions of ports. port select merely creates symlinks and so there is nothing to rely on there.

[EJFielding (Eric Fielding)]

I looked on my other Mac to see how it has gdal built. I see that it has the "+openmpi" variant added. That must be what I am missing on the Mac that failed to build gdal in this ticket.

It seems that the gdal port should be warning me that I need to add the "+openmpi" variant because my hdf5 is built with the "+openmpi" variant. That would be a lot more helpful than just failing to build. I had that warning from the netcdf port when I changed hdf5 to the openmpi variant.

[EJFielding (Eric Fielding)]

I got back to the Mac that was having trouble building gdal. I was able to get it to build by adding the +openmpi variant flag like this:

port install gdal +hdf5 +netcdf +postgresql95 +openmpi

It still seems like the gdal port should have warned me that I needed to add the +openmpi variant instead of failing to build without it.

[jjstickel (Jonathan Stickel)]

I suggest using active_variants to check for hdf5 +openmpi and add a warning/error message. See ​https://github.com/macports/macports-ports/pull/3102 .

[Veence (Vincent)]

• Outdated -