homebrew-core
homebrew-core copied to clipboard
Homebrew
hdf5 hdf5-mpi 1.14.4.3
- [x] Have you followed the guidelines for contributing?
- [x] Have you ensured that your commits follow the commit style guide?
- [x] Have you checked that there aren't other open pull requests for the same formula update/change?
- [x] Have you built your formula locally with
HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting? - [x] Is your test running fine
brew test <formula>, where<formula>is the name of the formula you're submitting? - [ ] Does your build pass
brew audit --strict <formula>(after doingHOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it passbrew audit --new <formula>?
/bin/sh ../libtool --tag=CC --mode=link mpicc -std=c99 -Wall -Warray-bounds -Wcast-qual -Wconversion -Wdouble-promotion -Wextra -Wformat=2 -Wframe-larger-than=16384 -Wimplicit-fallthrough -Wnull-dereference -Wunused-const-variable -Wwrite-strings -Wpedantic -Wvolatile-register-var -Wno-c++-compat -Wbad-function-cast -Wimplicit-function-declaration -Wincompatible-pointer-types -Wmissing-declarations -Wpacked -Wshadow -Wswitch -Wno-error=incompatible-pointer-types-discards-qualifiers -Wunused-function -Wunused-variable -Wunused-parameter -Wcast-align -Wformat -Wno-missing-noreturn -O3 -L/usr/local/opt/libaec/lib -o chunk_info chunk_info.o libh5test.la ../src/libhdf5.la -lsz -lz -ldl -lm
Undefined symbols for architecture x86_64:
"___truncxfhf2", referenced from:
_test_conv_flt_1 in dt_arith.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
/bin/sh ../libtool --tag=CC --mode=link mpicc -std=c99 -Wall -Warray-bounds -Wcast-qual -Wconversion -Wdouble-promotion -Wextra -Wformat=2 -Wframe-larger-than=16384 -Wimplicit-fallthrough -Wnull-dereference -Wunused-const-variable -Wwrite-strings -Wpedantic -Wvolatile-register-var -Wno-c++-compat -Wbad-function-cast -Wimplicit-function-declaration -Wincompatible-pointer-types -Wmissing-declarations -Wpacked -Wshadow -Wswitch -Wno-error=incompatible-pointer-types-discards-qualifiers -Wunused-function -Wunused-variable -Wunused-parameter -Wcast-align -Wformat -Wno-missing-noreturn -O3 -L/usr/local/opt/libaec/lib -o chunk_info chunk_info.o libh5test.la ../src/libhdf5.la -lsz -lz -ldl -lm Undefined symbols for architecture x86_64: "___truncxfhf2", referenced from: _test_conv_flt_1 in dt_arith.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
exact issue described in https://github.com/HDFGroup/hdf5/issues/4208
I could extract this from the vtk logs:
ld: library 'hdf5_hl-shared' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libvtkexodusII-9.3.9.3.dylib] Error 1
make[1]: *** [ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Looks related to https://gitlab.kitware.com/vtk/vtk/-/issues/17878, I'll notify upstream about this
Since vtk builds with current hdf5 (e.g. #181564), seems to be from change in 1.14.4
Are we going to have to rebase for the Sequoia bottles? If so, maybe after Linux finishes and hopefully can get cached (and hopefully "no conflicts" label prevents merging new Sequoia bottles otherwise will end up having trouble merging during mass bottling).
hopefully can get cached
cache is unlikely as lots of formulae are changing.
I suggest just merging master into here in the case of conflicts (and dropping any bottle changes from master in the merge). Merge is preferable to rebase so we don't destroy commit status information.
Dep tests were skipped so need to run that with https://github.com/Homebrew/homebrew-core/labels/CI-no-fail-fast-deps
octave failure on Linux (EDIT: maybe parallelization?):
c32_apply_type_test.c:19:10: fatal error: config.h: No such file or directory
19 | #include <config.h>
| ^~~~~~~~~~
vtk failure on 12-x86_64 may be slow runner:
==> /usr/local/Cellar/vtk/9.3.1_2/bin/vtkpython Distance2BetweenPoints.py
Killing child processes...
Error: vtk: failed
Error: vtk: failed
An exception occurred within a child process:
Timeout::Error: execution expired
We can wait a little bit until the Sequoia bottling slows down. It's never the best period to ship big updates like this one. This leaves me a little bit of time to investigate the octave failure.
Can probably continue this. Only the qt dependents aren't bottled, which are unlikely to be for some time as qt needs upstream fix (rewrite for ScreenCaptureKit).
Here is the octave error:
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32_apply_type_test.c -fPIC -DPIC -o .libs/libgnu_la-c32_apply_type_test.o
config.status: creating config.h
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32_get_type_test.c -fPIC -DPIC -o .libs/libgnu_la-c32_get_type_test.o
/bin/bash ../libtool --tag=CC --mode=compile gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c -o libgnu_la-c32isalpha.lo `test -f 'c32isalpha.c' || echo './'`c32isalpha.c
c32_apply_type_test.c:19:10: fatal error: config.h: No such file or directory
19 | #include <config.h>
| ^~~~~~~~~~
compilation terminated.
make[3]: *** [Makefile:4312: libgnu_la-c32_apply_type_test.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32isalnum.c -fPIC -DPIC -o .libs/libgnu_la-c32isalnum.o
/bin/bash ./build-aux/mk-octave-config-h.sh config.h > octave-config.h-t && \
if [ -s octave-config.h-t ]; then /bin/bash ./build-aux/move-if-change octave-config.h-t octave-config.h; else echo "octave-config.h-t is empty!" 1>&2; rm -f octave-config.h-t; exit 1; fi
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32isalpha.c -fPIC -DPIC -o .libs/libgnu_la-c32isalpha.o
make[3]: Leaving directory '/tmp/octave-20240910-418209-7ja7ph/octave-9.2.0/libgnu'
make[2]: *** [Makefile:6280: all-recursive] Error 1
make[2]: Leaving directory '/tmp/octave-20240910-418209-7ja7ph/octave-9.2.0/libgnu'
make[1]: *** [Makefile:3659: all] Error 2
make[1]: Leaving directory '/tmp/octave-20240910-418209-7ja7ph/octave-9.2.0/libgnu'
make: *** [Makefile:31380: libgnu/libgnu.la] Error 2
Isn't config.h usually generated during ./configure? Not sure how that would end up missing. Should have been found with -I. -I..
Probably will need to either repro or see if anything else in logs.
EDIT: Does show as generated in logs. Though the specific config.h may be created during make so could be parallelization issue.
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32_apply_type_test.c -fPIC -DPIC -o .libs/libgnu_la-c32_apply_type_test.o
config.status: creating config.h
libtool: compile: gcc-11 -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion -Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits -Wno-unsuffixed-float-constants -g -O2 -c c32_get_type_test.c -fPIC -DPIC -o .libs/libgnu_la-c32_get_type_test.o
Sadly the Sequoia run failed. May have been trying to grab non-existent bottle cache. EDIT: Same for deps test. Probably have to do run with cache disabled.
On side note, Octave passed so parallelization seems likely culprit.
Added https://github.com/Homebrew/homebrew-core/labels/no%20long%20build%20conflict so we hopefully merge after one last run.
This is blocking multiple PRs, so removing https://github.com/Homebrew/homebrew-core/labels/no%20long%20build%20conflict
==> Downloading https://code.mpimet.mpg.de/attachments/download/29646/cdo-2.4.4.tar.gz curl: (56) The requested URL returned error: 404 ==> Retrying download in 2s... (2 tries left) ==> Downloading https://code.mpimet.mpg.de/attachments/download/29646/cdo-2.4.4.tar.gz curl: (56) The requested URL returned error: 404 ==> Retrying download in 4s... (1 try left) ==> Downloading https://code.mpimet.mpg.de/attachments/download/29646/cdo-2.4.4.tar.gz curl: (56) The requested URL returned error: 404
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I strongly suspect this update, and particularly this line https://github.com/Homebrew/homebrew-core/pull/170959/files#diff-6dfd5ae69b1543e3bc621830b31efbf791e147e7030a37366f37038a7569141aR54, to be the cause of this build failure in the GDAL CI test suite: https://github.com/OSGeo/gdal/actions/runs/11071728335/job/30768851063?pr=10884:
ld: library not found for -lhdf5_hl
We haven't changed anything in our code related to HDF5/netCDF lately and that build configuration has just started failing today (and only the Homebrew one. We do link against libhdf5 & libnetcdf provided by other packaging systems). I've no local access to a Mac so it is not practical for me to inspect further.
You can try undoing it with doing something like
sed -i .bak 's/hdf5_hl;hdf5;/hdf5_hl-shared;hdf5-shared;/g' \
"$(brew --prefix netcdf)/lib/cmake/netCDF/netCDFTargets.cmake"
to see if it will help.
But I'm sceptical that that's the line at fault. I suggest building with CMAKE_VERBOSE_MAKEFILE=ON so we can get a better look at the failing compiler invocation. It might also help to build serially (i.e. -j 1) to make tracking down the exact command easier.
@carlocab Thanks for both suggestions!
- your sed trick did the job: https://github.com/rouault/gdal/actions/runs/11074368125/job/30773000210 is a green build
- CMAKE_VERBOSE_MAKEFILE=ON in https://github.com/rouault/gdal/actions/runs/11074368805/job/30773002569. I'm just putting here the relevant part of the offending linking line as GDAL is a huge library linking the whole world... So what appears is that a -lhdf5_hl is inserted there whereas GDAL itself only explicitly needs the -lhdf5 one (it uses the CMake FindHDF5 module with the
COMPONENTS "C"to retrieve the library)
hdf5_hl (i.e. -lhdf5_hl) should work in some environments but it doesn't guarantee the directory is on lookup path (i.e. -L#{HOMEBREW_PREFIX}/lib or -L#{HOMEBREW_PREFIX}/opt/hdf5/lib).
Original logic for hdf5_hl-shared is to pick up the CMake target, e.g.
hdf5-targets.cmake# Create imported target hdf5_hl-shared add_library(hdf5_hl-shared SHARED IMPORTED) set_target_properties(hdf5_hl-shared PROPERTIES INTERFACE_COMPILE_DEFINITIONS "H5_BUILT_AS_DYNAMIC_LIB" INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include" INTERFACE_LINK_LIBRARIES "hdf5-shared" )hdf5-targets-release.cmake:# Import target "hdf5_hl-shared" for configuration "Release" set_property(TARGET hdf5_hl-shared APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE) set_target_properties(hdf5_hl-shared PROPERTIES IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libhdf5_hl.310.0.4.dylib" IMPORTED_SONAME_RELEASE "@rpath/libhdf5_hl.310.dylib" )
The exact situation is a bit trickier as both HDF5 and NetCDF have issues in their CMake/pkg-config files in current releases. There are some fixes in HEAD for each.
Thanks for the update, @rouault. I've opened a PR to remove the workaround at #192118.
Incidentally, adding -L"$(brew --prefix netcdf)/lib" to your LDFLAGS is also likely to fix that build failure.