3.3. Compiler Notes
Open MPI requires a C99-capable compiler to build.
On platforms other than x86-64, AArc64 (64-bit ARM), and PPC, Open MPI requires a compiler that either supports C11 atomics or the GCC
__atomicatomics (e.g., GCC >= v4.8.x).
32-bit platforms are only supported with a recent compiler that supports C11 atomics. This includes GCC 4.9.x+ (although GCC 6.x or newer is recommended), the Intel compiler suite 16, and clang 3.1.
Mixing compilers from different vendors when building Open MPI (e.g., using the C/C++ compiler from one vendor and the Fortran compiler from a different vendor) has been successfully employed by some Open MPI users (discussed on the Open MPI user’s mailing list), but such configurations are not tested and not documented. For example, such configurations may require additional compiler / linker flags to make Open MPI build properly.
A not-uncommon case for this is when building on MacOS with the system-default GCC compiler (i.e.,
/usr/bin/gcc), but a 3rd party gfortran (e.g., provided by Homebrew, in
/usr/local/bin/gfortran). Since these compilers are provided by different organizations, they have different default search paths. For example, if Homebrew has also installed a local copy of Libevent (a 3rd party package that Open MPI requires), the MacOS-default
gcclinker will find it without any additional command line flags, but the Homebrew-provided gfortran linker will not. In this case, it may be necessary to provide the following on the configure command line:
shell$ ./configure FCFLAGS=-L/usr/local/lib ...
-Lflag will then be passed to the Fortran linker when creating Open MPI’s Fortran libraries, and it will therefore be able to find the installed Libevent.
In general, the latest versions of compilers of a given vendor’s series have the least bugs. We have seen cases where Vendor XYZ’s compiler version A.B fails to compile Open MPI, but version A.C (where C>B) works just fine. If you run into a compile failure, you might want to double check that you have the latest bug fixes and patches for your compiler.
Users have reported issues with older versions of the Fortran PGI compiler suite when using Open MPI’s (non-default)
--enable-debugconfigure option. Per the above advice of using the most recent version of a compiler series, the Open MPI team recommends using the latest version of the PGI suite, and/or not using the
--enable-debugconfigure option. If it helps, here’s what we have found with some (not comprehensive) testing of various versions of the PGI compiler suite:
pgi-8 : NO known good version with
pgi-9 : 9.0-4 known GOOD
pgi-10: 10.0-0 known GOOD
pgi-11: NO known good version with
pgi-12: 12.10 known BAD with
-m32, but known GOOD without
-m32(and 12.8 and 12.9 both known BAD with
pgi-13: 13.9 known BAD with
-m32, 13.10 known GOOD without
pgi-15: 15.10 known BAD with
Similarly, there is a known Fortran PGI compiler issue with long source directory path names that was resolved in 9.0-4 (9.0-3 is known to be broken in this regard).
Open MPI does not support the PGI compiler suite on OS X or MacOS. See issues below for more details:
OpenSHMEM Fortran bindings do not support the “no underscore” Fortran symbol convention. IBM’s
xlfcompilers build in that mode by default. As such, IBM’s
xlfcompilers cannot build/link the OpenSHMEM Fortran bindings by default. A workaround is to pass
FC="xlf -qextname"at configure time to force a trailing underscore. See https://github.com/open-mpi/ompi/issues/3612 for more details.
MPI applications that use the
mpi_f08module on PowerPC platforms (tested ppc64le) will likely experience runtime failures if:
they are using a GNU linker (ld) version after v2.25.1 and before v2.28, and
they compiled with PGI (tested 17.5) or XL (tested v15.1.5) compilers. This was noticed on Ubuntu 16.04 which uses the 2.26.1 version of
ldby default. However, this issue impacts any OS using a version of
ldnoted above. This GNU linker regression will be fixed in version 2.28. Here is a link to the GNU bug on this issue. The XL compiler will include a fix for this issue in a future release.
On NetBSD-6 (at least AMD64 and i386), and possibly on OpenBSD, Libtool misidentifies properties of f95/g95, leading to obscure compile-time failures if used to build Open MPI. You can work around this issue by ensuring that libtool will not use f95/g95 (e.g., by specifying
FC=<some_other_compiler>, or otherwise ensuring a different Fortran compiler will be found earlier in the path than
g95), or by disabling the Fortran MPI bindings with
On OpenBSD/i386, if you configure with
--enable-mca-no-build=patcher, you will also need to add
--disable-dlopen. Otherwise, odd crashes can occur nondeterministically.
Absoft 11.5.2 plus a service pack from September 2012 (which Absoft says is available upon request), or a version later than 11.5.2 (e.g., 11.5.3), is required to compile the Fortran
Open MPI does not support the Sparc v8 CPU target. However, as of Solaris Studio 12.1, and later compilers, one should not specify
-xarch=v9. The use of the options
-m64for producing 32 and 64 bit targets, respectively, are now preferred by the Solaris Studio compilers. GCC may require either
-mcpu=v9 -m32, depending on GCC version.
If one tries to build OMPI on Ubuntu with Solaris Studio using the C++ compiler and the
-m32option, you might see a warning:
CC: Warning: failed to detect system linker version, falling back to custom linker usage
And the build will fail. One can overcome this error by either setting
LD_LIBRARY_PATHto the location of the 32 bit libraries (most likely
/lib32), or giving
LDFLAGS="-L/lib32 -R/lib32"to the
configurecommand. Officially, Solaris Studio is not supported on Ubuntu Linux distributions, so additional problems might occur.
Open MPI does not support the
gccfsscompiler (GCC For SPARC Systems; a now-defunct compiler project from Sun).
At least some versions of the Intel 8.1 compiler seg fault while compiling certain Open MPI source code files. As such, it is not supported.
It has been reported that the Intel 9.1 and 10.0 compilers fail to compile Open MPI on IA64 platforms. As of 12 Sep 2012, there is very little (if any) testing performed on IA64 platforms (with any compiler). Support is “best effort” for these platforms, but it is doubtful that any effort will be expended to fix the Intel 9.1 / 10.0 compiler issuers on this platform.
Early versions of the Intel 12.1 Linux compiler suite on x86_64 seem to have a bug that prevents Open MPI from working. Symptoms including immediate segv of the wrapper compilers (e.g.,
mpicc) and MPI applications. As of 1 Feb 2012, if you upgrade to the latest version of the Intel 12.1 Linux compiler suite, the problem will go away.
Users have reported that the Intel Fortran compiler will fail to link Fortran-based MPI applications on macOS with linker errors similar to this:
Undefined symbols for architecture x86_64: "_ompi_buffer_detach_f08", referenced from: import-atom in libmpi_usempif08.dylib ld: symbol(s) not found for architecture x86_64
It appears that setting the environment variable
lt_cx_ld_force_load=nobefore invoking Open MPI’s
configurescript works around the issue. For example:
shell$ lt_cv_ld_force_load=no ./configure ...
The Portland Group compilers prior to version 7.0 require the
-Msignextendcompiler flag to extend the sign bit when converting from a shorter to longer integer. This is different than other compilers (such as GNU). When compiling Open MPI with the Portland compiler suite, the following flags should be passed to Open MPI’s
shell$ ./configure CFLAGS=-Msignextend CXXFLAGS=-Msignextend \ --with-wrapper-cflags=-Msignextend \ --with-wrapper-cxxflags=-Msignextend ...
This will both compile Open MPI with the proper compile flags and also automatically add
-Msignextendwhen the C and C++ MPI wrapper compilers are used to compile user MPI applications.
It has been reported that Pathscale 5.0.5 and 6.0.527 compilers give an internal compiler error when trying to build Open MPI.
As of July 2017, the Pathscale compiler suite apparently has no further commercial support, and it does not look like there will be further releases. Any issues discovered regarding building / running Open MPI with the Pathscale compiler suite therefore may not be able to be resolved.
Using the Absoft compiler to build the MPI Fortran bindings on Suse 9.3 is known to fail due to a Libtool compatibility issue.
There is now only a single Fortran MPI wrapper compiler and a single Fortran OpenSHMEM wrapper compiler:
The legacy executable names
mpif90still exist, but they are symbolic links to
mpifort. Users should immediately stop using the legacy names, and should always use
Similarly, Open MPI’s
configurescript only recognizes the
FCFLAGSenvironment variables (to specify the Fortran compiler and compiler flags, respectively). The
FFLAGSenvironment variables are IGNORED.
As a direct result, it is STRONGLY recommended that you specify a Fortran compiler that uses file suffixes to determine Fortran code layout (e.g., free form vs. fixed). For example, with some versions of the IBM XLF compiler, it is preferable to use
xlfwill automatically determine the difference between free form and fixed Fortran source code.
However, many Fortran compilers allow specifying additional command-line arguments to indicate which Fortran dialect to use. For example, if
FC=xlf90, you may need to use
mpifort --qfixed ...to compile fixed format Fortran source files.
You can use either
oshmem_infoto see with which Fortran compiler Open MPI was configured and compiled.
There are up to three sets of Fortran MPI bindings that may be provided (depending on your Fortran compiler):
mpif.h: This is the first MPI Fortran interface that was defined in MPI-1. It is a file that is included in Fortran source code. The only interface declared in Open MPI’s
MPI_SIZEOF(because of its polymorphism). All other interfaces are implicit.
mpimodule file was added in MPI-2. It provides strong compile-time parameter type checking for MPI all interfaces.
mpi_f08module was added in MPI-3. It provides many advantages over the
mpimodule. For example, MPI handles have distinct types (vs. all being integers). See the MPI-3.0 (or later) standard for more details.
mpi_f08module is STRONGLY recommended for all new MPI Fortran subroutines and applications. Note that the
mpi_f08module can be used in conjunction with the other two Fortran MPI bindings in the same application (only one binding can be used per subroutine/function, however). Full interoperability between
mpi_f08module MPI handle types is provided, allowing
mpi_f08to be used in new subroutines in legacy MPI applications.
Per the OpenSHMEM specification, there is only one Fortran OpenSHMEM binding provided:
shmem.fh: All Fortran OpenSHMEM programs should include
shmem.f, and Fortran OpenSHMEM programs that use constants defined by OpenSHMEM MUST include
The following notes apply to the above-listed Fortran bindings:
All Fortran compilers support the
shmem.fh-based bindings, with one exception: the
MPI_SIZEOFinterfaces will only be present when Open MPI is built with a Fortran compiler that supports the
ISO_FORTRAN_ENV. Most notably, this excludes the GNU Fortran compiler suite before version 4.9.
The level of support provided by the
mpimodule is based on your Fortran compiler.
If Open MPI is built with a non-GNU Fortran compiler, or if Open MPI is built with the GNU Fortran compiler >= v4.9, all MPI subroutines will be prototyped in the
mpimodule. All calls to MPI subroutines will therefore have their parameter types checked at compile time.
If Open MPI is built with an old
gfortran(i.e., < v4.9), a limited
mpimodule will be built. Due to the limitations of these compilers, and per guidance from the MPI-3.0 (and later) specification, all MPI subroutines with “choice” buffers are specifically not included in the
mpimodule, and their parameters will not be checked at compile time. Specifically, all MPI subroutines with no “choice” buffers are prototyped and will receive strong parameter type checking at run-time (e.g.,
Similar to the
MPI_SIZEOFis only supported on Fortran compilers that support
mpi_f08module has been tested with the Intel Fortran compiler and gfortran >= 4.9. Other modern Fortran compilers likely also work.
Many older Fortran compilers do not provide enough modern Fortran features to support the
mpi_f08module. For example,
gfortran< v4.9 does provide enough support for the
You can examine the output of the following command to see all the Fortran features that are/are not enabled in your Open MPI installation:
shell$ ompi_info | grep -i fort