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>
purpose. Continue to link the new library back to libopen-pal to resolve the renamed symbols.
Update opal configure logic to set disable_dlopen when disable_mca_dso is given. Fix typos in disable_dlopen when setting variables (incorrect inclusion of quotes)
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
Unlike "orterun", "prun" is a PMIx-only program that discovers the DVM connection instead of requiring that we explicitly provide it. Only build "prun" if PMIx v2.x is available.
This gets the DVM working again, but still is showing problems for multiple executions. I'll detail those in a separate issue. Thus, the DVM should still be considered "broken".
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
* Reference Issue #3546
* If the user specified `--without-lsf` then do not check for it
on the system, even if it is there. This can lead to the build
failure identified in the issue above.
Signed-off-by: Joshua Hursey <jhursey@us.ibm.com>
* Will display a message acknowledging the configure setting
instead of 'simple ok' which is misleading.
Signed-off-by: Joshua Hursey <jhursey@us.ibm.com>
though there are no C++ bindings for oshmem, we need C++ wrappers
since a C compiler might not be able to compile a C++ source.
the C++ wrappers are :
- shmemc++ / oshc++
- shmemcxx / oshcxx
- shmemCC / oshCC (on case sensitive filesystems)
also add the examples/hello_oshmem_cxx.cc example
Thanks Bert Wesarg for bringing this to our attention
Fixesopen-mpi/ompi#2097
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
* Removes support for big endian PPC
* Removes support for XL compiler older than 13.1
* Fixes Issue #4053
Signed-off-by: Joshua Hursey <jhursey@us.ibm.com>
This module was always intended to be a proof of concept, and was far
from complete. If/when someone implemented F08 descriptor support for
the mpi_f08 module, this commit can either be restored or used as
reference material.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
in order to solve an egg and the chicken problem, in which mpiext need mpi-f08-types.mod
and/but use-mpi-f08[-desc] needs mpiext, add an extra step
- build fortran 2008 modules only
- build fortran 2008 mpi extensions
- and then build fortran 2008 bindings
Fixesopen-mpi/ompi#3605
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Change the default enable configure option XRC to disabled. If a user want's
to give it a try they have to explicitly ask for it.
Modify the configury help message to indicate it is not enabled by default.
Related to #3890Fixes#3969
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
Every modern compiler supports either inline assembly or builtin atomic
operations. Because of this it is time to delete all the code associated
with pre-built atomics.
This commit also clean out the DEC and XLC asm checks. Neither check
does anything and the XLC compiler supports GCC ASM.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
This removes a copy-and-paste error where we were setting the
OPAL_ASM_SYNC_HAVE_64BIT more than once.
References #3993. Close when on master and v3.0.x.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
recent versions of PBS Pro requires libcrypto.so, but libpbs.so
does not (yet) depend on it, so manually add -lcrypto if -lpbs alone fails.
Thanks Petr Hanousek for bringing this to our attention
Refs PBSPro/pbspro#331
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
* This should be enough of a breadcrumb for when we get to fixing the
`INTERFACE` check to be strong enough to kick out gfortran 4.8
Signed-off-by: Joshua Hursey <jhursey@us.ibm.com>
test for both 32 and 64 bits.
clang only support 32 bits builtin atomics when -m32 is used
Thanks Paul Hargrove for reporting this.
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
We accepted a change that enabled CMA on s390 and s390x. This change
had the side-effect that we were no longer using the builtin atomics
for these systems. This is a problem since we do not have ASM for
s390 and s390x. This commit restores the atomics.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
the 'hostname' command might not be available on some platforms
such as Fedora Core 26, so mimick config/libtool.m4 and fallback
to 'uname -n' if needed
Refs. #3680
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Without this change, the directory of `javadoc` command must be
included in the `PATH` environment variable at `make`-time.
Paths of `javac`, `javah`, and `jar` commands are detected in
`configure`. So the path of `javadoc` also should be detected.
Signed-off-by: KAWASHIMA Takahiro <t-kawashima@jp.fujitsu.com>
The --enable-new-dtags option for the compiler wrappers is
often great, but for some particular install/usage scenarios
causes issues.
This commit provides a new configury option to use of rpath
in the compiler wrappers, but disables the
use of --enable-new-dtags in the link line.
The new configury option is
--enable-wrappers-runpath
To disable use of --enable-new-dtags in the wrappers, add
--disable-wrappers-runpath
to the Open MPI configury line.
Fixes#1089
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
