Unfortunately UCX 1.7.0 is appearing in RPMS before it's officially released.
There's a problem with Open MPI 4.0.x where x < 3 and this version of UCX,
namely that the UCT BTL fails to compile.
See https://github.com/open-mpi/ompi/issues/7128
This patch works around the problem by disabling the build of the UCT BTL
for releases 4.0.0 to 4.0.2.
add hppritcha (me) as maintainer
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
* Fixes:
1. MPI_THREAD_MULTIPLE problem with OpenMPI and UCX.
Changes:
1. OpenMPI provides two new depends_on options which result in UCX being compiled with multiple threads support. One implicit when OpenMPI 3.x is used, MPI_THREAD_MULTIPLE is enabled by default, and one explicit for OpenMPI <= 2.x, MPI_THREAD_MULTIPLE is disabled by default.
2. Extends UCX package to allow "Enable thread support in UCP and UCT" option.
3. Adds sha256 sums of UCX releases 1.6.1 and 1.2.0.
More details:
Fixes the issue with OpenMPI where programs which use MPI_THREAD_MULTIPLE will fail to execute because UCP worker didn't support it.
During the OpenMPI package installation it's the +thread_multiple spec was not propagated to UCX nor UCX handled it at all.
Now, the OpenMPI package is capable of handling +thread_multiple spec when UCX is request and the UCX package correctly handles +thread_multiple and compiles with the --enable-mt option.
Error message during runtime:
pml_ucx.c:226 Error: UCP worker does not support MPI_THREAD_MULTIPLE
* Adapts check of specs to read better and is the suggested form in the docs.
* Explicitly disables multithreading of UCX if +thread_multiple option is not used.
Note to spack people: these are expected to be end of line releases for both the 3.1.5 an 3.0.5 releases
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
We'd like to use a consistent checksum scheme everywhere so that we can:
a) incorporate archive checksums into our specs and have a
consistent hashing algorithm across all specs.
b) index mirrors with a consistent type of checksum, and not one that
is dependent on how spack packages are written.
- [x] convert existing md5, sha224, sha512, sha1 checksums to sha256
* Add LSF package, which cannot be installed by Spack and must be
system-installed. The package install will fail if no external
LSF is registered in packages.yaml (LSF may not be installed in a
well-known location and the external entry helps Spack locate it
for dependents).
* Add LSF dependency to OpenMPI when schedulers=lsf is chosen
* When fabrics=auto or schedulers=auto, the intent is to defer to the
OpenMPI configure and let it determine and use what it finds
available on the system. The current behavior for 'with_or_without'
in the case of 'auto' explicitly disables all possible values.
This updates the logic to call 'with_or_without' only when the
value of fabrics/schedulers is not 'auto'.
* To allow explicitly disabling all fabrics/schedulers, each of these
variants has added support for 'none' (which is also the default
value).
* Add a conflict for the loadleveler scheduler for openmpi-3 and
above as it is no longer a valid configure option.
This adds a stub script for mpirun and other standard executables
when installing OpenMPI with slurm. The purpose is to make the
removal less of a surprise to administrators/users: it explains why
they were removed and how to restore them.
shmemrun and oshrun do not exist in OpenMPI v4.0.0
(ref: https://www.open-mpi.org/doc/v4.0/)
The Spack OpenMPI package was failing the install by trying to
remove them. This guards the removal of several scripts when
using the Slurm scheduler to handle the case where they don't exist.
This enforces conventions that allow for correct handling of
multi-valued variants where specifying no value is an option,
and adds convenience functionality for specifying multi-valued
variants with conflicting sets of values. This also adds a notion
of "feature values" for variants, which are those that are understood
by the build system (e.g. those that would appear as configure
options). In more detail:
* Add documentation on variants to the packaging guide
* Forbid usage of '' or None as a possible variant value, in
particular as a default. To indicate choosing no value, the user
must explicitly define an option like 'none'. Without this,
multi-valued variants with default set to None were not parsable
from the command line (Fixes#6314)
* Add "disjoint_sets" function to support the declaration of
multi-valued variants with conflicting sets of options. For example
a variant "foo" with possible values "a", "b", and "c" where "c"
is exclusive of the other values ("foo=a,b" and "foo=c" are
valid but "foo=a,c" is not).
* Add "any_combination_of" function to support the declaration of
multi-valued variants where it is valid to choose none of the
values. This automatically defines "none" as an option (exclusive
with all other choices); this value does not appear when iterating
over the variant's values, for example in "with_or_without" (which
constructs autotools option strings from variant values).
* The "disjoint_sets" and "any_combination_of" methods return an
object which tracks the possible values. It is also possible to
indicate that some of these values do not correspond to options
understood by the package's build system, such that methods like
"with_or_without" will not define options for those values (this
occurs automatically for "none")
* Add documentation for usage of new functions for specifying
multi-valued variants
The latest OpenMPI release, v4.0.0, does not build with many GCC
variants. Since this is our default, a lot of users get hit.
Let's wait for some point releases.
- remove the old LGPL license headers from all files in Spack
- add SPDX headers to all files
- core and most packages are (Apache-2.0 OR MIT)
- a very small number of remaining packages are LGPL-2.1-only
This PR includes the following changes:
* Added JDK 10
* Changed the JDK version numbers according to the consensus reached
in #2284
* Added spec['java'].home and spec['java'].libs, similar to #3367
(JDK and IcedTea)
* Added a check to prevent people from installing JDK on macOS
* Set CLASSPATH for packages depending on Java (JDK and IcedTea)
* Add TODO for extending virtual packages (not currently possible)
* Add TODO for adding Java dependents to views
* Add TODO for packages which extend multiple packages (e.g. Java
and Python)
* Add latest release 3.0.2
https://www.open-mpi.org/software/ompi/v3.0/:x
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* 1. Added correct md5 sum for Open MPI v3.1.1 (https://www.open-mpi.org//software/ompi/v3.1/)
2. Made v3.1.1 the default version
3. Added libmpiso versions for v3.1.1 and 3.0.2
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* Added Open MPI v2.14 to version list; Tested build; Added libmpi.so version
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* Open MPI 3.1.2 built and tested
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* Add latest release 3.0.2
https://www.open-mpi.org/software/ompi/v3.0/:x
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* 1. Added correct md5 sum for Open MPI v3.1.1 (https://www.open-mpi.org//software/ompi/v3.1/)
2. Made v3.1.1 the default version
3. Added libmpiso versions for v3.1.1 and 3.0.2
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
* Added Open MPI v2.14 to version list; Tested build; Added libmpi.so version
Signed-off-by: Daniel Topa <dantopa@lanl.gov>
If the OpenMPI build finds the infiniband drivers in /usr/lib64, it adds
-Wl,-rpath -Wl,/usr/lib64 to the OpenMPI wrappers. If the wrappers are using
a compiler outside of /usr, and the OpenMPI wrappers are used to build software
outside of Spack, they will rpath /usr/lib64 into the executable which then has
GLIBC, GLIBCXX runtime errors due to it picking up GCC libraries in /usr/lib64.
This adds the directories specified in "extra_rpaths" to the OpenMPI wrappers,
which allows them to use the correct compiler when invoked outside of Spack
builds.
Modifications:
* Added zlib dependency, starting from version 3.0.0
* Added memchecker support for debugging
* Remove mpirun and similar links if slurm is selected as a scheduler
