> On Jan 27, 2016, at 11:32 PM, Jed Brown <[email protected]> wrote: > > Barry Smith <[email protected]> writes: >> I am just suggesting compile a file with #include <Hd5xxx.h> with no >> additional search paths (so it only checks the default locations) and if the >> compile succeeds we know there is an install of h5d that could cause >> problems. > > Once you detect that such a version exists, what are you going to do > about it? > > A typical situation is that /usr/lib/libhdf5.so is a non-parallel build > while some other location contains a libhdf5.so built to use a > particular MPI implementation. Those versions are fundamentally > different, but the system might use /usr/lib/libhdf5.so for lots of > other things and replacing it with the MPI version is not viable. If > you alert the user, their response is likely "Yes, I know it's > there. Now do the right thing." If you're capable of doing that, why > not just do it without bothering the user?
If the other package (i.e. trilinos) is incorrectly looking in the system location for the hdf5 include files before my installed location* (because somebody, as Satish said, got a -I/usr/include where it doesn't belong). Then I don't think I am capable of doing the right thing period! Hence I would stop and tell the person they either have to remove those files or they need to use them and not use --download-xxx period. Thus I propose if -download-hd5 is used and --download-trilinos we first check for system hdf5 and stop with an error if there are any. Objections? Barry *This is not speculation, this is what wasted my time debugging this afternoon.
