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>
