Per https://github.com/open-mpi/ompi/issues/3995, it should not be a
fatal error if the libnl checks fail. Instead, just fail the check
and let the upper layer decide what to do. In this case,
OPAL_CHECK_PACKAGE will mark this library as no good, and then
propagate that upward.
E.g., if libfoo fails the libnl check, and the user had specified
--with-libfoo, this will eventually cause configure to fail (because
the libnl check will fail with libfoo, which will cause
OPAL_CHECK_PACKAGE to fail with libfoo, which will ultimately cause
some upper-level logic to realize "a human asked for libfoo but we
could not provide it -- abort!").
However, if libfoo fails the libnl check and the user did *not*
specify --with-libfoo, then this will cause the upper layer to
silently skip libfoo (because the libnl check will fail libfoo, which
will cause OPAL_CHECK_PACKAGE to fail libfoo, but then the upper-level
logic will realize "oh, we can't use libfoo, but a human didn't ask
for it -- so just skip libfoo support.").
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
libnl and libnl-3 are known to conflict with each other, so detect
and abort if these two libs are both used directly (e.g. Open MPI
uses libnl-3) or indirectly (e.g. libibverbs.so might depend on libnl)
