CPU2017 benchmark 510.parest_r build failed with gcc9.3 and gcc9.4 - gcc

everyone.
I'm try to build CPU2017 intrate and fprate test set on aarch64 server with gcc9.3. All the benchmark build successed, except 510.parest_r. Then i try build it with gcc9.4, meet the same error. I used the Example-gcc-linux-aarch64.cfg as configure file, just edit the gcc path.
Here is the failed info:
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....
The failed info seem be caused by the MPRF float percision setting?
I tried build 510.parest_r with llvm-10, build success.
By the way, i build same gcc9.3 in x86_64 server, build 510.parest_r success.

You've found a bug in an older version of GCC (or possibly your system's RAM is failing, but unlikely if it consistently crashes at the same place). Or perhaps a bug in MPFR, although that seems less likely.
If you preprocess that source (add -E or -save-temps to the command line that crashed) and put it on https://godbolt.org/, does it still crash the same way with current ARM64 GCC, e.g. a nightly build of trunk? (https://godbolt.org/z/K6GnrYrj1 is ARM64 GCC trunk, with your command line args without the preprocessor stuff, which won't matter when compiling CPP output.)
If it still crashes with current GCC, then file a bug report on https://gcc.gnu.org/bugzilla/, ideally with a MCVE of the part of the source that triggers the bug. (Remove as many parts of the file as you can while preserving the crash behaviour. e.g. take out tons of stuff, undo if that makes it compile.)
If it doesn't crash with newer GCC, it might already be a known bug, or got fixed by accident, or a different MPFR or other library version mattered. In that case, maybe not worth reporting it upstream. Or if you do make sure to include the fact that the range of affected versions doesn't include GCC12 or current trunk. Probably this Stack Overflow Q&A is sufficient for future users to know that it's a known bug.

Related

What option controls whether GLSLang gets built in FFmpeg?

I'm using Media Autobuild Suite to build a more comprehensive FFmpeg executable for Windows than what's available in binaries distributed online, but I've encountered issues. I've resolved errors in a couple libraries by skipping them (commenting them out in ffmpeg_options.txt), but I'm stuck on the GLSLang module (OpenGL Shader Language). I've already disabled it and OpenGL in ffmpeg_options.txt as well as other switches labeled "options that add shared dependencies," and the suite is still trying to build it.
Disabled options:
#--enable-fontconfig
#--enable-libmfx
#--enable-decklink
#--enable-librist
#--enable-librtmp
#--enable-libssh
#--enable-libtesseract
#--enable-vapoursynth
#--enable-liblensfun
#--enable-libglslang
#--enable-vulkan
#--enable-opencl
#--enable-opengl
#--enable-cuda-nvcc
#--enable-libnpp
#--enable-libopenh264
The failed build generates an entire folder of logs, but here's the error message that prints in the console:
Running git clone for glslang...
Running git update for glslang...
┌ glslang git ........................................ [Recently updated]
├ Running dependencies...
Likely error (tail of the failed operation logfile):
CPPFLAGS: -D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1
CFLAGS: -mthreads -mtune=generic -O2 -pipe
CXXFLAGS: -mthreads -mtune=generic -O2 -pipe
LDFLAGS: -pipe -static-libgcc -static-libstdc++
/usr/bin/python ./update_glslang_sources.py
/usr/bin/python: can't open file '/build/glslang-git/./update_glslang_sources.py': [Errno 2] No such file or directory
dependencies failed. Check C:/mab_suite/build/glslang-git/ab-suite.dependencies.log
This is required for other packages, so this script will exit.
Creating diagnostics file...
Attach C:\mab_suite\build\logs.zip to the GitHub issue.
Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.
Try running the build again at a later time.
What modules/libraries do I have to fix or skip to prevent this error from causing the build to fail?

Compiling OpenFOAM's scotch on macOS

I am trying to compile the scotch library embedded into the OpenFOAM.org third-party repository here. I ran the command
make -C ./ThirdParty-dev/scotch_6.0.9/src/
and I get the below error message:
(cd libscotch ; make VERSION=6 RELEASE=0 PATCHLEVEL=9 scotch && make install)
make \
CC="gcc" \
CCD="gcc" \
scotch.h \
scotchf.h \
libscotch.so \
libscotcherr.so \
libscotcherrexit.so
gcc -O3 -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME -Drestrict=__restrict -DSCOTCH_VERSION_NUM=6 -DSCOTCH_RELEASE_NUM=0 -DSCOTCH_PATCHLEVEL_NUM=9 dummysizes.c -o dummysizes -Xlinker --no-as-needed -lz -lm -lrt
ld: unknown option: --no-as-needed
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [dummysizes] Error 1
make[1]: *** [scotch] Error 2
make: *** [libscotch] Error 2
I am not sure what this error message means. If it is complaining about scotch not being available, that's why I'm compiling it in the first place. Out of desperation, I also tried to install it via brew install scotch to no avail. I would appreciate it if you could help me understand the above error message and resolve the issue.
The scotch build is a bit different in that they manage all of the OS/compiler-specific bits separately via a src/Makefile.inc that the user is responsible for providing. Of course they also provide a number of examples in the src/Make.inc/ directory, but they may not properly cover your particular OS/compiler requirements.
Since you grabbed the scotch source files from a third-party source instead of from the pristine upstream sources, you also have someone else's src/Makefile.inc that happens to be a Linux-specific version. So no surprise that it has incorrect link (or even compile) options.
The Darwin-specific makefile adjustments that are used by openfoam.com:
# Linux:
LIB = .so
ARFLAGS = $(WM_CFLAGS) -shared -o
LDFLAGS = -Xlinker --no-as-needed $(WM_LDFLAGS) -lm -lrt
# Darwin:
LIB = .dylib
ARFLAGS = $(WM_CFLAGS) -dynamiclib -undefined dynamic_lookup -o
LDFLAGS = $(WM_LDFLAGS) -lm
Without worrying about any other source of differences (in the OpenFOAM WM_CFLAGS and WM_LDFLAGS variables), it would appear that you are using Linux (gcc only?) link options for Darwin - so should be no surprise that they don't work.
The location for the pristine scotch sources move around a bit (seems to be related to their filer) but a reasonably uptodate reference is always included in the OpenFOAM ThirdParty BUILD.md. The URLs are provided as links, but also listed near the bottom of the file for easy grepping.
The current scotch link : https://gforge.inria.fr/frs/download.php/file/38352/scotch_6.1.0.tar.gz
The newest scotch is actually scotch-6.1.2 but there appears to be a regression in the dgraph calculation (the distributed graph in ptscotch) so probably better to stick with 6.1.0 for now.
Here is the information for the scotch repo itself (https://gitlab.inria.fr/scotch/scotch) - should be the most reliable source of information.

/usr/local/include unintendedly added to my compile commands results in build failing

Background
I'm compiling, on a machine which runs macOS 10.15, a project which ships an old version of libpng (1.6.17) as a submodule. The corresponding code is available at https://github.com/glennrp/libpng. I also have libpng 1.6.37 installed by Homebrew.
Until not so long ago, I was able to compile libpng 1.6.17 using CMake without trouble. Since very recently (but the exact date is unknown to me), build fails with errors like:
FAILED: CMakeFiles/png16_static.dir/pngwutil.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -I/usr/local/include -I. -I../ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -MD -MT CMakeFiles/png16_static.dir/pngwutil.o -MF CMakeFiles/png16_static.dir/pngwutil.o.d -o CMakeFiles/png16_static.dir/pngwutil.o -c ../pngwutil.c
../pngwutil.c:2413:20: error: use of undeclared identifier 'PNG_WEIGHT_SHIFT'
PNG_WEIGHT_SHIFT;
^
I ran a few checks against a copy of my project I had which still compiled correctly because CMake wasn't re-running itself on it. The only difference between the two cases is a -I/usr/local/include flag added to compiler calls (I added some markup to help see the difference):
suceeds:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -Dpng16_EXPORTS -Iext_build/libpng -I../../ext/libpng -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fno-stack-protector -fomit-frame-pointer -fno-math-errno -ffp-contract=fast -march=native -MD -MT ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -MF ext_build/libpng/CMakeFiles/png16.dir/pngrio.o.d -o ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -c ../../ext/libpng/pngrio.c
<---------------------------------->
fails:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -Dpng16_EXPORTS -I/usr/local/include -Iext_build/libpng -I../../ext/libpng -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fPIC -fno-stack-protector -fomit-frame-pointer -fno-math-errno -ffp-contract=fast -march=native -MD -MT ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -MF ext_build/libpng/CMakeFiles/png16.dir/pngrio.o.d -o ext_build/libpng/CMakeFiles/png16.dir/pngrio.o -c ../../ext/libpng/pngrio.c
<------------------------------------------------------->
I re-ran CMake on the copy of the project which was working and I got the same error, which pointed me to a system-related problem. I then checked out directly the libpng sources and got the same error.
Steps to reproduce
Clone the libpng repo and check out v1.6.17
git clone https://github.com/glennrp/libpng.git
cd libpng
git checkout v1.6.17
Build libpng
cmake . -B build && cmake --build build
Question
What did add this -I/usr/local/include flag to my compiler calls?
Bonus question (maybe more interesting)
Now, it gets funny. If you checkout a more recent libpng (I tried with 1.6.21, 1.6.25, 1.6.28, 1.6.33 and 1.6.37), the problem goes away, although the flag is still here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -I/usr/local/include -I. -I../ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -MD -MT CMakeFiles/png16_static.dir/pngrio.o -MF CMakeFiles/png16_static.dir/pngrio.o.d -o CMakeFiles/png16_static.dir/pngrio.o -c ../pngrio.c
This means that I could update my submodule use one of these releases and my problem would go away.
However, if I'm not not mistaken, -I flags are resolved from left to right: I therefore suspect that my Homebrew headers are used instead of the source ones. If I'm right, then this doesn't guarantee that a Homebrew upgrade of libpng won't break the build again: it just shows that libpng's API has been stable since v1.6.21 and that I can use my Homebrew headers with the source I'm trying to compile. Am I right, or am I missing something?
answer to question: the system include path is added by compiler/preprocessor (this page will explain more datails)
the order of included in CMake project may be changed (not sure how much), CMake allows prepend includes in the list; try compare CMake build scripts between releases. I believe there will be mentioned change.
Yes sometimes cmake will pick up a variety of libs and include dirs and freely mix and match. If you need to keep multiple versions up, you should use the cmake command to pass the correct packages.
I finally got to the bottom of it. It turned out that libpng's zlib dependency was the one giving me trouble (indirectly).
What happened
MacOS ships zlib and it is usually known to developers who therefore don't feel the need to install a 3rd party zlib. However, CMake's find_package doesn't know about this preference and will pick up a zlib implementation found in /usr/local, for instance if it is installed by Homewbrew. For some reason, a zlib was installed by 3rd party software at this location on my system—not a Homebrew package, which made the detection more difficult, and it was detected by find_package.
The corresponding include directory is /usr/local/include. libpng's CMake code is such that this directory is then added to the list of include directories, which leads to the header conflicts mentioned in the question. I understood what was happening by going through CMakeCache.txt (searching for /usr/local/include), so the main lesson is: don't forget to check your CMake cache in such situations.
How to solve the problem
The lazy way. Remove the undesired lib files. I ran brew doctor and removed the files which were not supposed to be here. This, however, might have undesired consequences if the specific zlib version sitting in /usr/local is actually required by some piece of software.
The dirty CMake way. Modify the top-level CMake code to hint find_package about where it should pick zlib. Either hard-code the hint using the PATHS argument or set it using the ZLIB_ROOT argument (you might have to define policies for that).
I'm sure there is a better way to handle this by "doing CMake right" in libpng and forcing library search in system paths, but my CMake skills are not good enough to say what should be done exactly. And anyway, it's a bit off-topic with respect to the question.

gcc 4.8.1 compiling .c files as c++ in ubuntu 12.04

One of my users is getting an error message when trying to compile a C part of our mixed C/C++ codebase on ubuntu 12.04 with gcc 4.8.1
We have a library in C++ with some C-linkage functions in, and want to compile a C program linking to it. The library is compiled with g++ and builds fine. The c program fails like this:
> gcc -O3 -g -fPIC -I/media/Repo/lcdm/code/cosmosis/ -Wall -Wextra -pedantic -Werror -std=c99 -o c_datablock_t c_datablock_test.c -L . -lcosmosis
cc1plus: error: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [-Werror]
The program has a lower case .c file suffix, so why does gcc try to compile it as c++ ? We have not seen this on other OSes.
(I know we could kick the problem down the road by removing -Werror or handle this particular file with -x c but I'd like to solve the real problem.)
why does gcc try to compile it as c++
I can think of only two plausible explanations, and they both are end-user's fault.
It could be that the user transferred sources via Windows, and the file is really called C_DATABLOCK_TEST.C, and the user is misleading you.
It could also be that the user overwrote his gcc with g++ (surprisingly many people believe that gcc and g++ are the same thing, but they are not).
To disprove the first possibility, ask the user to execute his build commands under script, and send you resulting typescript.
To disprove the second, ask the user to add -v to the compile command.
This look like GCC Bug 54641, which has been fixed in a later release of GCC. It is only a warning, but your compile flags are causing GCC to treat all warnings as errors.

shared library locations for matlab mex files:

I am trying to write a matlab mex function which uses libhdf5; My Linux install provides libhdf5-1.8 shared libraries and headers. However, my version of Matlab, r2007b, provides a libhdf5.so from the 1.6 release. (Matlab .mat files bootstrap hdf5, evidently). When I compile the mex, it segfaults in Matlab. If I downgrade my version of libhdf5 to 1.6 (not a long-term option), the code compiles and runs fine.
question: how do I solve this problem? how do I tell the mex compilation process to link against /usr/lib64/libhdf5.so.6 instead of /opt/matlab/bin/glnxa64/libhdf5.so.0 ? When I try to do this using -Wl,-rpath-link,/usr/lib64 in my compilation, I get errors like:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libhdf5.so.0, needed by /opt/matlab/matlab75/bin/glnxa64/libmat.so, may conflict with libhdf5.so.6
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
mex: link of 'hdf5_read_strings.mexa64' failed.
make: *** [hdf5_read_strings.mexa64] Error 1
ack. the last resort would be to download a local copy of the hdf5-1.6.5 headers and be done with it, but this is not future proof (a Matlab version upgrade is in my future.). any ideas?
EDIT: per Ramashalanka's excellent suggestions, I
A) called mex -v to get the 3 gcc commands; the last is the linker command;
B) called that linker command with a -v to get the collect command;
C) called that collect2 -v -t and the rest of the flags.
The relevant parts of my output:
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/crtbeginS.o
hdf5_read_strings.o
mexversion.o
-lmx (/opt/matlab/matlab75/bin/glnxa64/libmx.so)
-lmex (/opt/matlab/matlab75/bin/glnxa64/libmex.so)
-lhdf5 (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/libhdf5.so)
/lib64/libz.so
-lm (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/libm.so)
-lstdc++ (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so)
-lgcc_s (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libgcc_s.so)
/lib64/libpthread.so.0
/lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2
-lgcc_s (/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libgcc_s.so)
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/crtn.o
So, in fact the libhdf5.so from /usr/lib64 is being referenced. However, this is being overriden, I believe, by the environment variable LD_LIBRARY_PATH, which my version of Matlab automagically sets at run-time so it can locate its own versions of e.g. libmex.so, etc.
I am thinking that the crt_file.c example works either b/c it does not use the functions I am using (H5DOpen, which had a signature change in the move from 1.6 to 1.8 (yes, I am using -DH5_USE_16_API)), or, less likely, b/c it does not hit the parts of Matlab internals that need hdf5. ack.
The following worked on my system:
Install hdf5 version 1.8.4 (you've already done this: I installed the source and compiled to ensure it is compatible with my system, that I get gcc versions and that I get the static libraries - e.g. the binaries offered for my system are icc specific).
Make a target file. You already have your own file. I used the simple h5_crtfile.c from here (a good idea to start with this simple file first a look for warnings). I changed main to mexFunction with the usual args and included mex.h.
Specify the static 1.8.4 library you want to load explicitly (the full path with no -L for it necessary) and don't include -lhdf5 in the LDFLAGS. Include a -t option so you can ensure that there is no dynamic hdf5 library being loaded. You also need -lz, with zlib installed. For darwin we also need a -bundle in LDFLAGS:
mex CFLAGS='-I/usr/local/hdf5/include' LDFLAGS='-t /usr/local/hdf5/lib/libhdf5.a -lz -bundle' h5_crtfile.c -v
For linux, you need an equivalent position-independent call, e.g. fPIC and maybe -shared, but I don't have a linux system with a matlab license, so I can't check:
mex CFLAGS='-fPIC -I/usr/local/hdf5/include' LDFLAGS='-t /usr/local/hdf5/lib/libhdf5.a -lz -shared' h5_crtfile.c -v
Run the h5_crtfile mex file. This runs without problems on my machine. It just does a H5Fcreate and H5Fclose to create "file.h5" in the current directory, and when I call file file.h5 I get file.h5: Hierarchical Data Format (version 5) data.
Note that if I include a -lhdf5 above in step 3, then matlab aborts when I try to run the executable (because it then uses matlab's dynamic libraries which for me are version 1.6.5), so this is definitely solving the problem on my system.
Thanks for the question. My solution above is definitely much easier for me than what I was doing before. Hopefully the above works for you.
I am accepting Ramashalanka's answer because it led me to the exact solution which I will post here for completeness only:
download the hdf5-1.6.5 library from the hdf5 website, and install the header files in a local directory;
tell mex to look for "hdf5.h" in this local directory, rather than in the standard location (e.g. /usr/include.)
tell mex to compile my code and the shared object library provided by matlab, and do not use the -ldfh5 flag in LDFLAGS.
the command I used is, essentially:
/opt/matlab/matlab_default/bin/mex -v CC#gcc CXX#g++ CFLAGS#"-Wall -O3 -fPIC -I./hdf5_1.6.5/src -I/usr/include -I/opt/matlab/matlab_default/extern/include" CXXFLAGS#"-Wall -O3 -fPIC -I./hdf5_1.6.5/src -I/usr/include -I/opt/matlab/matlab_default/extern/include " -O -lmwblas -largeArrayDims -L/usr/lib64 hdf5_read_strings.c /opt/matlab/matlab_default/bin/glnxa64/libhdf5.so.0
this gets translated by mex into the commands:
gcc -c -I/opt/matlab/matlab75/extern/include -DMATLAB_MEX_FILE -Wall -O3 -fPIC -I./hdf5_1.6.5/src -I/usr/include -I/opt/matlab/matlab_default/extern/include -O -DNDEBUG hdf5_read_strings.c
gcc -c -I/opt/matlab/matlab75/extern/include -DMATLAB_MEX_FILE -Wall -O3 -fPIC -I./hdf5_1.6.5/src -I/usr/include -I/opt/matlab/matlab_default/extern/include -O -DNDEBUG /opt/matlab/matlab75/extern/src/mexversion.c
gcc -O -pthread -shared -Wl,--version-script,/opt/matlab/matlab75/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -o hdf5_read_strings.mexa64 hdf5_read_strings.o mexversion.o -lmwblas -L/usr/lib64 /opt/matlab/matlab_default/bin/glnxa64/libhdf5.so.0 -Wl,-rpath-link,/opt/matlab/matlab_default/bin/glnxa64 -L/opt/matlab/matlab_default/bin/glnxa64 -lmx -lmex -lmat -lm -lstdc++
this solution should work on all my various target machines and at least until I upgrade to matlab r2009a, which I believe uses hdf5-1.8. thanks for all the help, sorry for being so dense with this--I think I was overly-committed to using the packaged version of hdf5, rather than a local set of header files.
Note this would all have been trivial if Mathworks had provided a set of the header files with the Matlab distribution...

Resources