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.
