Per today's telecon, check for supported version and do not use anything less than 1.2.x. Sadly, we don't include the last piece of the version triplet in the version file and so we cannot check for 1.2.5.
If someone explicitly points us at an external installation that isn't acceptable, then error out
Add PMIx support to summary
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
- added implementation and/or/xor operations for post and
fetch-op notations
- implemented basic and UCX transports, mxm added
NON-IMPLEMENTED wrapper
- updated C interfaces only (fortran will be added later)
- existing API is not updated to spec v1.4
Signed-off-by: Sergey Oblomov <sergeyo@mellanox.com>
so latest ROM-IO can be used with Open MPI.
Note this first and naive implementation does not use the wait_fn callback.
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
This commit adds a new btl for one-sided and two-sided. This btl
uses the uct layer in OpenUCX. This btl makes use of multiple uct
contexts and per-thread device pinning to provide good performance
when using threads and osc/rdma. This btl has been tested extensively
with osc/rdma and passes all MTT tests on aries and IB hardware.
For now this new component disables itself but can be enabled by
setting the btl_ucx_transports MCA variable with a comma-delimited
list of supported memory domains/transport layers. For example:
--mca btl_uct_memory_domains ib/mlx5_0. The specific transports used
can be selected using --mca btl_uct_transports. The default is to use
any available transport.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
Revamp OPAL_PROG_CC_C11 macro in order to define macros only once.
Otherwise, macros get redefined during the configure process and
issue a bunch of warning in config.log. That would also cause
Open MPI fail to build if compiled with "-Werror"
Refs. open-mpi/ompi#5190
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
configure: add checks for `__thread` on top of current check for `_Thread_local` and define OPAL_HAVE_THREAD_LOCAL if the compiler support TLS.
Added `opal_thread_local` keyword to unify the definition.
Signed-off-by: Thananon Patinyasakdikul <thananon.patinyasakdikul@intel.com>
If a subroutine of the Fortran `use-mpi-f08` binding in an MPI extension
have a `LOGICAL` parameter and no `TYPE(MPI_Status)` parameter,
it needs to use the `mpi_ext` module and call its corresponding subroutine
in the `mpif-h` directory, as explained in
`ompi/mpi/fortran/use-mpi-f08/mpi-f-interfaces-bind.h`.
However, as shown in the figure below, the required directories are dependent
on each other, and "Can't open module file" error occurs at build time.
ompi/mpiext/{extension name}/use-mpi-f08
A |
| |
| V
ompi/mpi/fortran/use-mpi-f08 <--- ompi/mpi/fortran/mpiext (mpi_ext.mod)
In order to solve this problem, change the configuration and the build order.
- divide Fortran extension directory (`ompi/mpi/fortran/mpiext`)
into the directories for `use-mpi` and for `use-mpi-08`
- `ompi/mpi/fortran/mpiext-use-mpi` : for `use-mpi` (mpi_ext.mod)
- `ompi/mpi/fortran/mpiext-use-mpi-f08` : for `use-mpi-08` (mpi_f08_ext.mod)
- change to the following build order about Fortran `use-mpi` and
`use-mpi-f08` bindings in `ompi`
1. mpi_ext bindings of MPI extensions (`mpiext/{extension name}/use-mpi` directory)
2. Fortran use-mpi (`mpi/fortran/use-mpi-[ignore-]tkr` directory)
3. Fortran extension for use-mpi (`mpi/fortran/mpiext-use-mpi` directory)
4. Fortran use-mpi-f08 modules only (`mpi/fortran/use-mpi-f08/mod` directory)
5. mpi_f08_ext bindings of MPI extensions (`mpiext/{extension name}/use-mpi-f08` directory)
6. Fortran use-mpi-f08 (`mpi/fortran/use-mpi-f08` directory)
7. Fortran extension for use-mpi-f08 (`mpi/fortran/mpiext-use-mpi-f08` directory)
Signed-off-by: Kurita, Takehiro <fj6370fp@aa.jp.fujitsu.com>
This is a minor abstraction break in naming, but hopefully acceptable for now. I will update the contents of the program a little later. This resolves the immediate issue of naming conflict with the PRRTE binary.
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
This commit adds a new configure option: --enable-mpi1-compat. Without
this option we will no longer provide APIs, typedefs, and defines that
were removed from the standard in MPI-3.0. This option will exist for
one major release (Open MPI v4.x.x) and then the option and associated
code will be removed in Open MPI v5.x.x. Open MPI has already
internally prepared for this change. Please prepare your codes
accordingly.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
This patch disables the oshmem layer if there are no SPMLs that
will build. With the limited set of SPMLs available to support
oshmem, many builds end up installing an oshmem library that we
know will not work. There has been a bit of customer confusion
over oshmem, hopefully this will lead customers in the right
direction.
Signed-off-by: Brian Barrett <bbarrett@amazon.com>
Two related changes to allow projects to not build based on
configure test results, as opposed to only reacting to
user configure options today. Use case is disabling a project
like oshmem because no communication channels can be built.
First, Move PROJECT_* AM_CONDITIONALs from the top of configure to
the bottom, so that we can change the results during configure.
Second, add a DIST_SUBDIRS to Makefile.am (and populate it in
opal_mca) so that "make dist" will work even when a project is
disabled.
Signed-off-by: Brian Barrett <bbarrett@amazon.com>
enable_oshmem holds the result of a customer decision and, like
most user options, can have the values "yes" (user wants us to
build feature), "no" (user wants us not to build feature),
"" (user wants us to figure it out), and "<something>" (user
wants us to build feature, with <something> turned on).
This change updates oshmem to not lose this data by not overwriting
enable_oshmem with a yes/no and leaving the original customer
intent in place. Aside from fixing one bug (below) there are no
customer visible changes in this patch, but it makes it possible
to do the right thing in the upcoming work to allow oshmem to be
disabled based on test results.
There was a cosmetic bug in the existing code where specifying
a feature argument (like --enable-oshmem=awesome) would result
in the "checking if want oshmem" test reporting no, but oshmem
being built anyway. With this cleanup, the "checking if want
oshmem" test, the final output summary, and what actually happens
will all match.
Signed-off-by: Brian Barrett <bbarrett@amazon.com>
The Java configury is split into two parts:
1. Determine if we want MPI Java bindings.
2. Find the Java compiler (and related).
This commit does a few things:
- Move the "Find the Java compiler" step from OPAL to OMPI (because
there is no Java in OPAL, and there doesn't appear to be any
immanent danger that there will be).
- As a direct consequence, remove the --enable-java CLI option
(--enable-mpi-java still remains). Enabling the MPI Java bindings
and enabling Java are now considered the same thing (since there
is no Java elsewhere in the code base, the different was
meaningless).
- Only invoke the "Find the Java compiler" step if we actually want
the MPI Java bindings.
- A few miscellaneous Java-related cleanups in configury (E.g., change
testing "$foo" == "1" to $foo -eq 1, etc.
This commit is mostly s/opal/ompi/gi in many places in configury and
shifting code around. But it looks bigger than it actually is because
of two reasons:
1. Some files were renamed:
* ompi_setup_java.m4 -> ompi_setup_mpi_java.m4 (setup MPI Java bindings)
* opal_setup_java.m4 -> ompi_setup_java.m4 (setup Java compiler)
2. Indenting level changed in (the new) ompi_setup_java.m4.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
That PR accidentally changed Open MPI's build configuration infrastruc-
ture's Java toolchain detection logic so that it would, as reported by @bosilca
in https://github.com/open-mpi/ompi/pull/5001#issuecomment-387803012 and tracked down by me in https://github.com/open-mpi/ompi/pull/5001#issuecomment-387851005, abort your entire
in-progress Open MPI build when it failed to find an OS X/macOS JDK instead of
simply falling back to checking for a JDK in locations where it would be found
on other platforms. _Oops…!_
Signed-off-by: Bryce Glover <RandomDSdevel@gmail.com>
similar patch to the lustre version, abandon the configure
macro for the pvfs2 components if the user explicitely told you
to do that.
Signed-off-by: Edgar Gabriel <egabriel@central.uh.edu>
make sure we actually respect if the user set the --without-lustre
flag (instead of continuing in the m4 macro as was the case until now).
Signed-off-by: Edgar Gabriel <egabriel@central.uh.edu>
javah is no more available from Java 10, so try
javac -h first (available since Java 8) and fallback on javah
Refs. open-mpi/ompi#5000
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
The NAG Fortran check only matched "nagfor" exactly, and failed if a
path to nagfor was provided. Also change "-pthread" into
"-Wl,-pthread".
Signed-off-by: Themos Tsikas <themos.tsikas@nag.co.uk>
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
and do not end up with -L/usr/lib[64] when PMI libraries
are installed in the default location.
Thanks Davide Vanzo for the report.
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
This reverts commit c4fe4ecfb9.
Revert "Fix DIR, DIR/include search for --with-pmix"
This reverts commit 2e3f401763.
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
This commit updates the configure code for Open MPI to check for C11
support. The features requested are: atomics and thread local
storage.
References #3879
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
- if --with-zlib=DIR --with-zlib-libdir=LIBDIR are given, do not search
libs in DIR/lib[64], and do not abort if libs are not there
- if --with-zlib=DIR is given but not --with-zlib-libdir, then do append
-LDIR/lib[64] to LDFLAGS
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
- when --with-ucx=DIR is not set, try the default path and fallback to /opt/ucx
- when --with-ucx-libdir is not set, try lib64 and then lib directories
- do not handle --with-ucx-libdir (this is a user mistake, no need to over-complicate our logic)
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
We no longer officially support MIPS or ARM before v6. This commit
updates the configury to check for sync builtins on these
architectures and removes the MIPS and IA64 assembly from
opal/include/opal/sys.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
Give packagers a configure CLI option to set the value of the MCA
variable mca_base_component_show_load_errors.
The --disable form of this option is intended for Open MPI packagers
who tend to enable support for many different types of networks and
systems in their packages. For example, consider a packager who
includes support for both the FOO and BAR networks in their Open MPI
package, both of which require support libraries (libFOO.so and
libBAR.so). If an end user only has BAR hardware, they likely only
have libBAR.so available on their systems -- not libFOO.so. Disabling
load errors by default will prevent the user from seeing potentially
confusing warnings about the FOO components failing to load because
libFOO.so is not available on their systems.
Conversely, system administrators tend to build an Open MPI that is
targeted at their specific environment, and contains few (if any)
components that are not needed. In such cases, they might want their
users to be warned that the FOO network components failed to load
(e.g., if libFOO.so was mistakenly unavailable), because Open MPI may
otherwise silently failover to a slower network path for MPI traffic.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
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>
