3.4. Compiler Notes — Open MPI 5.0.10 documentation

# 3.4. 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 `__atomic` atomics (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 `gcc` linker 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 ...

  This `-L` flag 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-debug` configure 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-debug` configure 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 `--enable-debug`

  - pgi-9 : 9.0-4 known GOOD

  - pgi-10: 10.0-0 known GOOD

  - pgi-11: NO known good version with `--enable-debug`

  - pgi-12: 12.10 known BAD with `-m32`, but known GOOD without `-m32` (and 12.8 and 12.9 both known BAD with `--enable-debug`)

  - pgi-13: 13.9 known BAD with `-m32`, 13.10 known GOOD without `-m32`

  - pgi-15: 15.10 known BAD with `-m32`

- 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:

  - https://github.com/open-mpi/ompi/issues/2604

  - https://github.com/open-mpi/ompi/issues/2605

- OpenSHMEM Fortran bindings do not support the “no underscore” Fortran symbol convention. IBM’s `xlf` compilers build in that mode by default. As such, IBM’s `xlf` compilers 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_f08` module 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 `ld` by default. However, this issue impacts any OS using a version of `ld` noted 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 `f95`/`g95`), or by disabling the Fortran MPI bindings with `--disable-mpi-fortran`.

- 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 `mpi_f08` module.

- 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=v8plus` or `-xarch=v9`. The use of the options `-m32` and `-m64` for producing 32 and 64 bit targets, respectively, are now preferred by the Solaris Studio compilers. GCC may require either `-m32` or `-mcpu=v9 -m32`, depending on GCC version.

- If one tries to build OMPI on Ubuntu with Solaris Studio using the C++ compiler and the `-m32` option, 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_PATH` to the location of the 32 bit libraries (most likely `/lib32`), or giving `LDFLAGS="-L/lib32 -R/lib32"` to the `configure` command. Officially, Solaris Studio is not supported on Ubuntu Linux distributions, so additional problems might occur.

- Open MPI does not support the `gccfss` compiler (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=no` before invoking Open MPI’s `configure` script 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 `-Msignextend` compiler 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 `configure` script:

      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 `-Msignextend` when 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: `mpifort` and `oshfort`, respectively.

  Caution

  The legacy executable names `mpif77` and `mpif90` still exist, but they are symbolic links to `mpifort`. Users should immediately stop using the legacy names, and should always use `mpifort`.

  Similarly, Open MPI’s `configure` script only recognizes the `FC` and `FCFLAGS` environment variables (to specify the Fortran compiler and compiler flags, respectively). The `F77` and `FFLAGS` environment variables are IGNORED.

  Important

  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 `FC=xlf` instead of `FC=xlf90`, because `xlf` will 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 `ompi_info` or `oshmem_info` to 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):

  1. `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 `mpif.h` is `MPI_SIZEOF` (because of its polymorphism). All other interfaces are implicit.

  2. `mpi` module: The `mpi` module file was added in MPI-2. It provides strong compile-time parameter type checking for MPI all interfaces.

  3. `mpi_f08` module: The `mpi_f08` module was added in MPI-3. It provides many advantages over the `mpif.h` file and `mpi` module. For example, MPI handles have distinct types (vs. all being integers). See the MPI-3.0 (or later) standard for more details.

  Important

  The `mpi_f08` module is STRONGLY recommended for all new MPI Fortran subroutines and applications. Note that the `mpi_f08` module 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 `mpif.h`/`mpi` module and `mpi_f08` module MPI handle types is provided, allowing `mpi_f08` to 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 `shmem.fh`.

  The following notes apply to the above-listed Fortran bindings:

  - All Fortran compilers support the `mpif.h`/`shmem.fh`-based bindings, with one exception: the `MPI_SIZEOF` interfaces will only be present when Open MPI is built with a Fortran compiler that supports the `INTERFACE` keyword and `ISO_FORTRAN_ENV`. Most notably, this excludes the GNU Fortran compiler suite before version 4.9.

  - The level of support provided by the `mpi` module 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 `mpi` module. 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 `mpi` module 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 `mpi` module, 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., `MPI_INIT`, `MPI_COMM_RANK`, etc.).

    Similar to the `mpif.h` interface, `MPI_SIZEOF` is only supported on Fortran compilers that support `INTERFACE` and `ISO_FORTRAN_ENV`.

  - The `mpi_f08` module 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_f08` module. For example, `gfortran` < v4.9 does provide enough support for the `mpi_f08` module.

  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