I'm trying to install PL/R on Mountain Lion 10.8.2, I've installed R 2.15.3 from r-project and PostgreSQL 9.1 from KyngChaos. I've got PL/R 8.3.0.14 from http://www.joeconway.com/plr/. I've put the expanded folder in /usr/local/pgsql/share/contrib and cd'd into that folder.
The environment variables $R_HOME and $CUSTOM_COPT are set as instructed at http://www.joeconway.com/web/guest/pl/r/-/wiki/Main/Installation_Mac by writing them into .bash_profile, and also added /library/frameworks/r.framework/resources/bin to my path by writing to the same file.
XCode 4.6 and the Command Line Tools are installed. There are multiple copies of standard C header files, including stdio.h, for example there is /usr/include/stdio.h.
Next step seems to be:
DiMac:plr duncan$ make
Makefile:40: ../../src/Makefile.global: No such file or directory
Makefile:41: /contrib/contrib-global.mk: No such file or directory
make: *** No rule to make target `/contrib/contrib-global.mk'. Stop.
That didn't work, and then I try:
DiMac:plr duncan$ make USE_PGXS=1
gcc -Os -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -D_FILE_OFFSET_BITS=64 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -arch x86_64 -I"." -I"-I/library/frameworks/r.framework/resources/include" -I/library/frameworks/r.framework/resources/include -I. -I. -I/usr/local/pgsql-9.1/include/server -I/usr/local/pgsql-9.1/include/internal -I/usr/include/libxml2 -DPKGLIBDIR=\"/usr/local/pgsql-9.1/lib\" -DDLSUFFIX=\".so\" -DR_HOME_DEFAULT=\"/library/frameworks/r.framework/resources\" -c -o plr.o plr.c
In file included from /usr/local/pgsql-9.1/include/server/postgres.h:47,
from plr.h:38,
from plr.c:33:
/usr/local/pgsql-9.1/include/server/c.h:67:19: error: stdio.h: No such file or directory
/usr/local/pgsql-9.1/include/server/c.h:68:20: error: stdlib.h: No such file or directory
...
and then pages more of errors.
It seems to me that make is looking in the wrong place for the standard header files and can't find them.From my reading around it seems that the flag -isysroot is telling gcc to look for header files by prepending the normal search path(s) with the /developer.../macosx10.6.sdk path and this path does not exist on my machine, which I believe is standard with the current version of Xcode.
So, the question:
Is this flag set somehow by the Makefile within /plr, or is it set somewhere else? Either way, how do I change it to get make to find the header files that it needs? If changing it is, indeed, the correct thing to do?
I've managed to bodge a solution to my own question. Maybe someone can help with tidying it up?
make USE_PGXS=1 formats a series of flags and then calls gcc with the flags it's calculated. So, I copied and pasted the line gcc... above and then changed the path after -isysroot to be one where the standard header files are found. Then the command runs properly, and compiles the file it's been told to.
I had to do this several times, once for each file to be compiled, until a full set exists, and then repeat the exercise using make install instead.
After many runs at this, I ended up with the shared object I needed in the right location, and then resumed following the instructions from Joe Conway's wiki.
It works great now. It would be great to know how to stop/change the -isysroot setting permanently.
I use MacPorts's postgresql92 +python +perl variant (after earlier compiling PostgreSQL myself) and it has worked flawlessly in each of the recent builds I've done on three computers: http://iangow.wordpress.com/2013/06/26/install-plr-on-os-x-10-8-4-using-macports/ (description of earlier process here: http://iangow.wordpress.com/2012/05/21/plr-on-os-x/).
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
I'm trying to build Google's Skia library on Mac, but when I try running
ninja -C out/Static/
in order to build the library, it gives me this error (after many, many similar errors):
[14/1073] compile ../../src/gpu/GrBackendTextureImageGenerator.cpp
FAILED: obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
c++ -MD -MF obj/src/gpu/gpu.GrBackendTextureImageGenerator.o.d -DNDEBUG -DSK_ASSUME_GL=1 -DSK_ENABLE_API_AVAILABLE -DSK_GAMMA_APPLY_TO_A8 -DSKIA_IMPLEMENTATION=1 -DSK_GL -I../.. -Wno-attributes -fstrict-aliasing -fPIC -fvisibility=hidden -isysroot b\'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\\n\' -O3 -Wno-sign-conversion -Wno-unused-parameter -std=c++17 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -c ../../src/gpu/GrBackendTextureImageGenerator.cpp -o obj/src/gpu/gpu.GrBackendTextureImageGenerator.o
clang: warning: no such sysroot directory: 'b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n'' [-Wmissing-sysroot]
In file included from ../../src/gpu/GrBackendTextureImageGenerator.cpp:8:
In file included from ../../include/gpu/GrContext.h:11:
In file included from ../../include/core/SkMatrix.h:11:
In file included from ../../include/core/SkRect.h:11:
In file included from ../../include/core/SkPoint.h:11:
In file included from ../../include/core/SkMath.h:11:
../../include/core/SkTypes.h:26:18: fatal error: 'TargetConditionals.h' file not found
#include "TargetConditionals.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
It seems like the sysroot directory b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk\n' is wrong, however "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk" does exist and "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/" has the file TargetConditionals.h.
I haven't used ninja before, but I tried looking in toolchain.ninja but could find no way to change the sysroot variable. I also reinstalled Xcode and Xcode command line tools, to no avail. Any help would be greatly appreciated!
I too struggled a lot. The solutions that I tried:
xcode-select --install for installing command line tools. But it used to say that command line tools are already installed.
Tried re-installing xcode to fix some linkage issue.
Tried a could of other solutions found on web.
Finally, what worked for me is by switching to python2. I had python2 and python3 installed. My path environment variable in .zshrc was giving precedence to python3. So, all internal scripts generated by ninja had python3 in precedence.
I temporarily removed python3, you can keep both but its precedence should be changed. Then regenerate build directory using gn. Then use ninja to build.
Note:
clang: warning: no such sysroot directory: 'b'/Applications/ : Here 'b' use to represent that string literal should be treated as byte literal in python3. So that could be the cause.
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.
I am trying to compile a project that required freetype library so I was figuring out how to install freetype to mingw32 and the more safer way is to compile it.
Anyway the problem was compiling freetype-2.4.11
I went into bash provided in msys
I did ./configure within freetype's main dir and everything looks fine
next I did mingw32-make which created the problem
libtool: compile: gcc -pedantic -ansi -Ig:/Downloads/freetype-2.4.11/objs -I./b
uilds/unix -Ig:/Downloads/freetype-2.4.11/include -c -Wall -g -O2 "-DFT_CONFIG_C
ONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" g
:/Downloads/freetype-2.4.11/src/base/ftsystem.c -DDLL_EXPORT -DPIC -o g:/Downlo
ads/freetype-2.4.11/objs/.libs/ftsystem.o
Assembler messages:
Fatal error: can't create g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o: No
such file or directory
g:/Downloads/freetype-2.4.11/builds/freetype.mk:198: recipe for target 'g:/Downl
oads/freetype-2.4.11/objs/ftsystem.lo' failed
mingw32-make[4]: *** [g:/Downloads/freetype-2.4.11/objs/ftsystem.lo] Error 1
g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o seemed like it is trying to use a directory that is illegal in windows.
Thanks in advance
Try to use make instead (i.e. the one from MSYS distribution), and avoid using mingw32-make (from MinGW distribution) in the future to save yourself time and nerves. Extract from MinGW Wiki:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.
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...