Fix paths for Ubuntu 16.04+ and Debian 9 #18
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is another approach that I've adopted to fix issue #16, but different in style to pull request #17 so might serve as an alternative choice. Gotta say these packages are a bit of a pain to use from a CMake perspective, but this is the least intrusive solution I could come up with.
The issue is that newer Ubuntu and Debian packages construct libraries that install into locations of the form:
/usr/lib/petscdir/VERSION/ARCH/lib/libpetsc_ARCH.so
. Following the usual Debian guidelines, these (and header includes) are then symlinked into places such as/usr/lib/libpetsc.so
and friends, depending on the real/complex architecture choice selected inupdate-alternatives
. This means that definingPETSC_DIR
andPETSC_ARCH
no longer works on these distributions, since the CMake configuration cannot find thelibpetsc_ARCH.so
library.The solution I have used here is to instead direct CMake to look inside
/usr/lib/petsc
first, which in these newer distributions is a symlink to thepetscdir/VERSION/ARCH
that has been selected by the user inupdate-alternatives
. This has the advantage of no longer needing to look in hard-coded version-specific locations or hack around withPETSC_ARCH
, and from the command line the library is detected automatically without manually specifying paths. However, the disadvantage is that we now need to additionally look forlibpetsc_real.so
andlibpetsc_complex.so
. Right now no other distributions use these alternative names, as far as I know, but I guess this could potentially be a cause for concern longer-term.