before:
patch_dir=$PLATFORM.patches
after
patch_dir can be specified as ./configure <....> patch_dir=/usr/local/site_ompi_v_x.y_patches/
if not specified - use default
./configure --with-platform=contrib/platform/$name will apply all patches
found in contrib/platform/$name.patches/ directory during "configure" phase.
It allows vendors to distribute not-accepted or vendor-specific patches as
part of standard ompi tarball and reduce burden of keeping private repos.
Added:
* VPATH support
* $srcdir/.platform_patches file created if patches already applied
* configure will fail with error if patch cannot be applied (using dry-run)
* configure will fail if patches modifying *.[am,m4] files (unsupported)
* remove unused patch_errors var
* set with_ident_string if platform file applied patches
The tkr m4's fortran couldn't be compiled
by gfortran. pointer assignment followed by
variabl definition didn't compile.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
The Intel 2016 compiler suite apparently only partially supports the
!GCC pragmas (prior versions either didn't support it at all, or our
existing configure test was sufficient to disqualify !GCC pragma
support when compiling with the Intel compiler).
With the existing configure test, the Intel 2016 compiler suite would
*pass* the test and therefore think that it could use !GCC as the
"ignore TKR" pragma. However, the "!GCC ATTRIBUTES NO_ARG_CHECK"
pragma doesn't work with scalar integers (although it seems to work
for the other types in this test).
This commit adds a scalar integer test to the ignore TKR pragma
configure test, which is enough to make the Intel 2016 compiler suite
fail with !GCC (this then allows configure to advance on to trying the
!DEC pragma, which *does* work properly with the Intel 2016 compiler
suite).
Thanks to Fabrice Roy for reporting the problem.
Fixesopen-mpi/ompi#937.
As of v15.7, the PGI Fortran compiler does not properly support how
Open MPI uses the "USE ... ONLY" Fortran syntax to include modules
with conflicting symbol definitions (interestingly, pgfortran only has
a problem with this when compiling with -g).
In short, OMPI uses "USE :: module_aaa, ONLY: foo" and "USE ::
module_bbb, ONLY: bar" to use modules aaa and bbb, even though they
contain conflicting definitions for some symbols. However, the use of
the ONLY clause should preclude the inclusion of the conflicting
symbols -- as the word implies, it should direct the compiler to
*only* use the symbols identified by the clause (i.e., foo and bar, in
this example).
This commit adds a configure test for this capability. If the
compiler fails to build a simple test that mimics this behavior, then
disable the mpi_f08 bindings.
Fixesopen-mpi/ompi#857
Only set OMPI_FORTRAN_BUILD_SIZEOF to 1 if $ompi_fortran_happy is also
1 (i.e., we're building the Fortran interface). This prevents
building [p]size_f.f90 and trying to compile it if there is no Fortran
compiler, for example.
This commit removes alpha asm support. No current processor
manufacturer makes chips compatible with DEC alpha and no
participating organization has alpha processors. This makes it
difficult to support alpha via assembly.
This doesn't mean Open MPI will no longer build/work on alpha
processors. It should continue to work with gcc's builtin sync
atomics.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
Fortran uses objects (ompi_f08_mpi_comm_world, mpi_fortran_bottom,, ...) that are defined in C.
Some compilers have different requirements on how these objects should be aligned.
Smaller alignment in C can lead to several confusing warnings from the linker, so try to
find the alignment expected by Fortran compiler, and inform the C compiler.
configury: fix hcoll, fca and mxm detection and revamp yalla Makefile.am
Thanks to David Shrader and Ake Sandgren for bringing this issue to our attention
* do not add -I/.../include/fca -I /.../include/fca_core to CPPFLAGS
* allow configure --with-fca
* search fca libs in both DIR/lib and DIR/lib64
* fix the description of the --with-fca option
* do not add -I/.../include/hcoll -I /.../include/hcoll/api to CPPFLAGS
* allow configure --with-hcoll
* search hcoll libs in both DIR/lib and DIR/lib64
* fix the description of the --with-hcoll option
Previously, extensions were required to have a config.h for their C
bindings. This commit allows them to have a config.h.in, in case
their C bindings header file is generated.
only define the unique fortran symbol depending on
- CAPS
- PLAIN
- SINGLE_UNDERSCORE
- DOUBLE_UNDERSCORE
and bind the f08 symbol to the uniquely defined C symbol.
Use real data structures to make the code simpler.
(perl script written by Jeff)
since ibv_create_xrc_rcv_qp is now deprecated, and in order to
be "future-proof", we have to consider the case in which only XRC Domains are supported.
also, correctly handle distro that ship broken ibverbs devel headers
Thanks Paul Hargrove for the detailled report.
@ggouaillardet is likely offline for the weekend, but master is broken
on RHEL 6.5 systems that do not have MOFED installed. So I'm taking
the liberty of revering this commit; I'm guessing Gilles will fixup
and re-commit next week.
This reverts commit 77f8282d51.
since ibv_create_xrc_rcv_qp is now deprecated, and in order to
be "future-proof", we have to consider the case in which only XRC Domains are supported.
Thanks Paul Hargrove for the detailled report.
* affinity: will build unless disabled.
* cr: will build if FT is enabled, unless it is disabled. It will
also complain/abort if you --with-mpi-ext=cr, but FT is disabled.
* example: will only build if --with-mpi-ext=example (and .ompi_ignore
is removed)
This new MTL runs over PSM2 for Omni Path. PSM2 is a descendant of PSM
with changes to support more ranks and some MPI-3 features like mprobe.
PSM2 will only support Omni Path networks; PSM only supports True Scale.
Likewise, the existing PSM MTL will continue to be maintained for True
Scale, while the PSM2 MTL is developed and maintained for Omni Path.
* Add a few minor comments
* Rename $OMPI_WANT_FORTRAN_BINDINGS -> $OMPI_MIN_REQUIRED_FORTRAN_BINDINGS
* Minor whitespace cleanups
* Change an "if ..." to an AS_IF
Fujitsu compilers used with the GNU compatibility option (-Xg)
do not yet support all the gnu flags (e.g. -pedantic) and that can
cause the linker (and hence configure) crash.
Fujitsu compilers are identified by the __FUJITSU macro.
This adds a check at `make install` time to look for common symbols. It
attempts to ignore "Fortran-shaped" symbols by default. It also will
look in the source tree for any files named "common_sym_whitelist" and
will ignore any symbols listed in that file (one per line, comments
allowed).
See open-mpi/ompi#375 for more background.
== Short version
Do not export special variables into the environment (e.g., LIBS,
LDFLAGS, etc.) when invoking subdir configure scripts. This prevents
problems described in open-mpi/ompi#471.
== More detail
Exporing special env variables before invoking a subdir configure
script causes problems in some cases. E.g., in open-mpi/ompi#471,
when the user configures with `--with-hwloc=/path/to/hwloc`, and that
directory is *not* in a default linker search location will cause the
libevent subdir configuration to fail.
This happens because:
1. We'll pass LIBS="-L/path/to/hwloc/lib -lhwloc" to the libevent
configure script
1. Meaning: configure-generated executables will link successfully
1. But unless LD_LIBRARY_PATH (or some other
tell-the-linker-where-to-find-things mechanism) includes
/path/to/hwloc/lib, the executable can't run.
Specifically, the libevent "hey, does the compiler generate proper
executables?" check will fail, and configure will abort (because OMPI
needs libevent).
I checked the history: exporting these vars dates all the way back to
LAM/MPI. I can't think of a reason why we need to export these
variables -- AC_CONFIG_SUBDIRs doesn't do it; subdir configure scripts
should be orthogonal from the upper-layer configure script (and its
variables). So let's remove these export statements and see if
anything breaks.
Some versions of clang (at least >= 3.5 -- perhaps older versions,
too?) will *warn* about -finline-functions, but still allow it. This
is very annoying, so check for that warning, too.
Per discussion on devel
(http://www.open-mpi.org/community/lists/devel/2015/02/17030.php), and
per Autoconf 2.69 docs, use the recommended AC_SEARCH_LIBS instead of
AC_CHECK_LIB (e.g., for functions that appear in libc on some
platforms and in a specific library on other platforms).
Use of this configuration option can cause crashing, hanging, and
(worse) incorrect results when btl/sm, btl/scif, or btl/vader are
in use. We discussed this at the January 2015 developers meeting
and it was decided to remove the option entirely. This commit does
just that. All usage of OPAL_WANT_SMP_LOCKS has been removed.
Honestly, a bunch of this code could use similar treatment (i.e.,
AC_DEFUN a template that can be used for OPAL/ORTE/OMPI). However, I
don't quite have time for this today. Exercise left for the future reader...
The RPATH support added a @{libdir} token into
<package>_WRAPPER_EXTRA_LDFLAGS. However, these flags are also
substituted into the pkg-config data files, and they don't understand
the @{foo} notation. So convert @{libdir} into ${libdir}, which
pkg-config *does* understand.
Thanks to Christoph Junghans (@junghans) for notifying us of the issue.
Fixes#406.
It used to be important to get the latest config.sub and config.guess
from upstream because architectures were changing rapidly, and the GNU
Autotools released super-slowly.
However, architectures have not been changing nearly as fast -- the
versions of config.guess and config.sub that ship in the GNU Autotools
are fine. So let's stop getting upstream config.guess|sub from
upstream as part of "make dist".
per several reports on the devel ML, the opal_lifo test hangs
with intel icc 14.0.0.080 (aka 2013sp1) and intel icc 14.0.1.106 (aka 2013sp1u1).
/* older and more recents compilers work fine
* buggy compilers work also fine but only with -O0 */
Some systems have XRC symbols in their libibverbs libraries, but do
not have the appropriate XRC bits in their devel headers (cough cough
RHEL 6.5 libibverbs-rocee-*.x86-64.rpm cough cough).
So expand the XRC config checks to ensure that we can actually find
one of the XRC constants that we need to compile XRC code before
ruling that we can actually build XRC support.
Use the pkg-config related m4 functions to find out where
Cray's xpmem.h and libxpmem are located on a system.
With this commit, there is no longer any need to have to
explicitly indicate an xpmem install location on the configure
line, at least for Cray systems running CLE 4.X and 5.X.
Turns out the OPAL_FLAGS_UNIQ function was chopping
off multiple instances of --param when set in the
CFLAGS. This can happen when -mnative or other machine
target is specified as part of CFLAGS.
Thanks to QuesarVII for reporting this and supplying a patch.
Fixes#324
Before this commit we checked if the compiler supported compare-and-exchange
on 128-bit values. This turned out to be insufficient. This commit strengthens
the check to see if the processor supports the instruction (or built-in). This
check will not work when cross-compiling (will always disable the 128-bit
atomic) so overrides have been added for this case.
1. Ensure to override CFLAGS properly. Move the setting of CFLAGS outside the AM_CONDITIONAL so that Automake doesn't get confused (because CFLAGS is already set inside an AM_CONDITIONAL -- moving it outside the conditional ensure that this local CFLAGS override trumps all other CFLAGS overrides).
2. Only build libfabric on Linux. Add a little more configury to ensure that we only try to build libfabric on Linux.
3. Remove a dead/unused file
4. Fix typo in condition check
5. Use "false", not "/bin/false"
This commit represents the conversion of the usnic BTL from verbs to
libfabric.
For the moment, libfabric is embedded in Open MPI (currently in the
usnic BTL). This is because the libfabric API is still changing, and
also has not yet been released. Ultimately, this embedded copy of
libfabric will likely disappear and the usnic BTL will rely on an
external installation of libfabric.
New configure options:
* --with-libfabric: will cause configure to fail if libfabric support
cannot be built
* --without-libfabric: will prevent libfabric support from being built
* --with-libfabric=DIR: use an external libfabric installation
* --with-libfabric-libdir=LIBDIR: when paired with --with-libfabric=DIR,
use LIBDIR for the libfabric installation library dir
The --with-libnl3[-libdir] arguments are now gone.
Some versions of gcc require this flag to be set before the __sync
builtin atomic compare and swap will support 128-bit values. If the
flag is required this check adds the flag to the CFLAGS.
A 128-bit compare-and-swap will enable a better atomic lifo implementation
that uses the pointer + counter method to avoid ABA issues. This commit
adds configury to check for the instruction (cmpxchg16b) and adds an
implementation that uses the __int128 type available in C99.
Clean up the orte_check_alps.m4. There was a little of
unnecesary stuff for handling cle 5, since it wasn't actually
doing the right thing, which would be to use pkg-config to
find dependencies both for dynamic and static linking.
Decouple the searching for alps libs, etc. from cray pmi.
Switch the alps ess and alps odls components' config files
to use the ALPS m4 macro.
alps configury fixes
Improve a check for detecting CLE release.
Improve an error message.
Currently only shows whether opal_mca.m4 decides whether to build a
component or not. This will be helpful in debugging a remote user's
setup that somehow, mysteriously decides not to build a specific
component.
Change the CPPFLAGS to just -I$srcdir, and change the include file to
check to be just opal/libltdl/ltdl.h. Do this because the CPPFLAGS
are passed to the preprocessor, and the C program that is passed
through the preprocessor is basically:
#include <opal/libltdl/ltdl.h>
Using the proper -I covers both VPATH and non-VPATH cases.
The mixing of the Slurm PMI and Cray PMI configure was getting
messy and dangerous - developers working on Slurm PMI often don't
have access to Cray PMI, etc.
This mod pulls out the Cray PMI configure into a separate m4 file.
Cray pmi is now configured as follows:
1) on Cray CLE 5 and higher, Cray PMI is auto detected. pkg-config
is used to resolve the necessary CPP flags, link flags and libs,
etc. Nothing needs to be added to the configure line to pick up
Cray PMI.
2) on legacy Cray CLE 4 systems with PMI 4.X, Cray PMI is also
auto detected.
3) on legacy Cray CLE 4 systems with PMI 5.X Cray PMI can't be auto-detected
owing to changes in the PMI pkg-config file which result in pkg-config
returning an error owing to a dependency of PMI on newer versions of ALPS
installs that are not present on CLE 4. So, for those falling in to this
situation, the --with-cray-pmi=(DIR) method needs to be used.
DIR specifies the Cray PMI install directory. The configure file looks
for required alps libraries first in /usr/lib/alps, then in
/opt/cray/xe-sysroot/default/usr/lib/alps.
In OMPI 1.8 and 1.8.1, we didn't allow gfortran to use the ignore-TKR
style "mpi" Fortran module (which is written in Fortran). Instead,
gfortran used the TKR style "mpi" module, which is written in C.
In OMPI 1.8.2, we removed the gfortran restriction (for suitably
modern gfortran -- i.e., >= 4.9). This allowed gfortran to use the
ignore-TKR style "mpi" module, but exposed a bug where MPI Fortran
sentinel values wouldn't be linked properly on OS X. The solution is
to use ```-Wl,-flat_namespace``` (see the OS X ld(1) man page for
details) when both building the libraries and in the wrapper
compilers.
Thanks to Github user yafshar for rasising the issue.
Fixes#259.
Per #257, the configure test used to check:
```c
```
But out in the code base, we actually do this:
```c
// ...
```
This commit updates the configure test to ```#define``` a string and
then use that with the various ident strategies.
Fixes#257
There is a continued interest in being able to do static
linking of executables. When using pkg-config to determine
linking requirements, the default behavior is to only
specify libraries required for dynamic linking.
In many cases, it suffices even for static linking to
use
pkg-config --libs package
to obtain the linkage string required for ld. However, for
libraries that have dependencies on non-standard libraries,
this may not be the case. The cray PMI library is such a case.
On a Cray CLE 5.X system, for example
pkg-config --libs cray-pmi
returns a string like
-L/opt/cray/pmi/5.0.2-1.0000.9906.117.2.ari/lib64 -lpmi
whereas
pkgconfig --static --libs cray-pmi
returns a string (modified for git commits) like
-L/opt/cray/pmi/5.0.2-1.0000.9906.117.2.ari/lib64
-L/opt/cray/ugni/5.0-1.0000.8563.255.10.ari/lib64
-L/opt/cray/alps/6.0.0-2.0000.8544.102.21.ari/lib64
-L/opt/cray/wlm_detect/1.0-1.0000.48964.8.2.ari/lib64
-L/opt/cray/rca/1.0.0-2.0000.49383.133.60.ari/lib64
-lpmi -lpthread -lalpslli -lpthread -lwlm_detect
-lugni -lpthread -lalpsutil -lpthread -lrca
Unfortunately the pkg.m4 does not contain a function for adding
the --static option to PKG_CHECK_MODULES. This commit defines
a new function, PKG_CHECK_MODULES_STATIC, which in addition to
defining the $1_CFLAGS and $1_LIBS variables defined by PKG_CHECK_MODULES,
also defines a $1_STATIC_LIBS.
We must also set the static library filenames properly (i.e., obey the
$FRAMEWORK_LIB_PREFIX that was set). Hence, set the prefixes earlier
in configure.ac, and update OPAL_MCA to set the static library names
properly.
These two macros set the MCA prefix and MCA cmd line id,
respectively. Specifically, MCA parameters will be named
PREFIX<foo> in the environment, and the cmd line will use
-ID foo bar.
These macros must be called during configure.ac and a value
supplied. In the case of Open MPI, the values given are
PREFIX=OMPI_MCA_ and ID=mca.
Other projects (such as ORCM) will call these macros with
their own unique values. For example, ORCM uses PREFIX=ORCM_MCA_
and ID=omca
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running OMPI applications under ORCM, we need the MCA params passed
to the ORCM daemons to be separated from those recognized by the OMPI application.
These two macros set the prefix for the OPAL and ORTE libraries,
respectively. Specifically, the OPAL library will be named
libPREFIXopen-pal.la and the ORTE library will be named
libPREFIXopen-rte.la.
These macros must be called, even if the prefix argument is empty.
The intent is that Open MPI will call these macros with an empty
prefix, but other projects (such as ORCM) will call these macros with
a non-empty prefix. For example, ORCM libraries can be named
liborcm-open-pal.la and liborcm-open-rte.la.
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running MPI applications under ORTE, if the ORTE and OPAL
libraries between OMPI and ORCM are not identical (which, because they
are released at different times, are likely to be different), we need
to ensure that the OMPI applications link against their ORTE and OPAL
libraries, but the ORCM executables link against their ORTE and OPAL
libraries.
This commit makes the folowing changes:
- Add support for the knem single-copy mechanism. Initially vader will only
support the synchronous copy mode. Asynchronous copy support may be added
int the future.
- Improve Linux cross memory attach (CMA) when using restrictive ptrace
settings. This will allow Open MPI to use CMA without modifying the system
settings to support ptrace attach (see /etc/sysctl.d/10-ptrace.conf).
- Allow runtime selection of the single copy mechanism. The default behavior
is to use the best available. The priority list of single-copy mehanisms is
as follows: xpmem, cma, and knem.
- Allow disabling support for kernel-assisted single copy.
- Some tuning and bug fixes.
Update the VERSION file scheme:
* Remove "want_repo_rev".
* Add "tarball_version".
All values are now always included (major, minor, release, greek,
repo_rev). However, configure.ac now runs "opal_get_version.sh
... --tarball", which will return the value of tarball_version (if it
is non-empty) or the "full" version string (i.e.,
"major.minor.releasegreek").
Remove configure.params support: configure.params hasn't been used in
years.
Also remove autogen.subdirs support; those should really be handled by
their respective Makefile.am's.
This is a first cut at updating various infrastructure for git. There
will definitely be more commits; some of the scripts require
committed/pushed code (e.g., the various make-tarball scripts). So
it's not possible to know if we got it right without committing/pushing.
In all previous releases, the version number would be "A.B.C" unless C
was 0, in which case it would be "A.B". This commit changes that
scheme to always be "A.B.C", even if C==0.
Hence, v1.9.0 will be the first release where this new scheme is evident.
This commit was SVN r32816.
It's not enough to AC_COMPILE_IFELSE, do AC_LINK_IFELSE to really make
sure the compiler suite supports it.
Refs trac:4917
This commit was SVN r32802.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
* remove config/ompi_config_solaris_threads.m4 which was dead code
* check if pthreads work "as is" on all platforms including Solaris
(FWIW, the test should have been skipped if Solaris threads are used
and not if configure is ran on a Solaris box)
Refs trac:4911
This commit was SVN r32792.
The following Trac tickets were found above:
Ticket 4911 --> https://svn.open-mpi.org/trac/ompi/ticket/4911
gfortran 4.8 does not support storage_size() on all relevant types
that we need. So add a configure test to check and see if the
compiler's storage_size() intrinsic supports enough types for us to do
MPI_SIZEOF.
Also remove an accidentally redundant check for fortran INTERFACE.
Refs trac:4917
This commit was SVN r32790.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
1. Fixes according to (http://www.open-mpi.org/community/lists/devel/2014/09/15869.php)
2. Force mpisync:rank0 to gather results. Now sync info is written by rank0 to the output file.
3. Improve mpirun_prof: 1) adopt to the environment (SLURM/TORQUE); 2) recognize some noteset-related mpirun options.
This commit was SVN r32772.
What started as a simple ticket ended up reaching the way up to the
MPI Forum.
It turns out that we are supposed to have MPI_SIZEOF for all Fortran
interfaces: mpif.h, the mpi module, and the mpi_f08 module.
It further turns out that to properly support MPI_SIZEOF, your Fortran
compiler *has* support the INTERFACE keyword and ISO_FORTRAN_ENV. We
can't use "ignore TKR" functionality, because the whole point of
MPI_SIZEOF is that the implementation knows what type was passed to it
("ignore TKR" functionality, by definition, throws that information
away). Hence, we have to have an MPI_SIZEOF interface+implementation
for all intrinsic types, kinds, and ranks.
This commit therefore adds a perl script that generates both the
interfaces and implementations for MPI_SIZEOF in each of mpif.h, the
mpi module, and mpi_f08 module (yay consolidation!).
The perl script uses the results of some new configure tests:
* check if the Fortran compiler supports the INTERFACE keyword
* check if the Fortran compiler supports ISO_FORTRAN_ENV
* find the max array rank (i.e., dimension) that the compiler supports
If the Fortran compiler supports both INTERFACE and ISO_FORTRAN_ENV,
then we'll build the MPI_SIZEOF interfaces. If not, we'll skip
MPI_SIZEOF in mpif.h and the mpi module. Note that we won't build the
mpi_f08 module -- to include the MPI_SIZEOF interfaces -- if the
Fortran compiler doesn't support INTERFACE, ISO_FORTRAN_ENV, and a
whole bunch of ther modern Fortran stuff.
Since MPI_SIZEOF interfaces are now generated by the perl script, this
commit also removes all the old MPI_SIZEOF implementations (which were
laden with a zillion #if blocks).
cmr=v1.8.3
This commit was SVN r32764.
