Fix rpath linking for NAG, add documentation on setup (#2142)
This commit is contained in:
Adam J. Stewart
Todd Gamblin
parent
dd53ddb003
commit
58409a2eaf
3 changed files with 57 additions and 27 deletions
|
|
@ -324,7 +324,7 @@ by adding the following to your ``packages.yaml`` file:
|
|||
compiler: [gcc@4.9.3]
|
||||
|
||||
|
||||
.. note::
|
||||
.. tip::
|
||||
|
||||
If you are building your own compiler, some users prefer to have a
|
||||
Spack instance just for that. For example, create a new Spack in
|
||||
|
|
@ -393,11 +393,13 @@ build your own, plus modules:
|
|||
|
||||
#. Once the compiler is installed, you should be able to test it by
|
||||
using Spack to load the module it just created, and running simple
|
||||
builds (eg: ``cc helloWorld.c; ./a.out``)
|
||||
builds (eg: ``cc helloWorld.c && ./a.out``)
|
||||
|
||||
#. Add the newly-installed compiler to ``compilers.yaml`` as shown
|
||||
above.
|
||||
|
||||
.. _mixed-toolchains:
|
||||
|
||||
^^^^^^^^^^^^^^^^
|
||||
Mixed Toolchains
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
|
@ -509,16 +511,17 @@ compilers:
|
|||
features (``spack install gcc``).
|
||||
|
||||
#. Tell the Intel compiler how to find that desired GCC. This may be
|
||||
done in one of two ways: (text taken from `Intel Reference Guide
|
||||
<https://software.intel.com/en-us/node/522750>`_):
|
||||
done in one of two ways:
|
||||
|
||||
> By default, the compiler determines which version of ``gcc`` or ``g++``
|
||||
> you have installed from the ``PATH`` environment variable.
|
||||
>
|
||||
> If you want use a version of ``gcc`` or ``g++`` other than the default
|
||||
> version on your system, you need to use either the ``-gcc-name``
|
||||
> or ``-gxx-name`` compiler option to specify the path to the version of
|
||||
> ``gcc`` or ``g++`` that you want to use.
|
||||
"By default, the compiler determines which version of ``gcc`` or ``g++``
|
||||
you have installed from the ``PATH`` environment variable.
|
||||
|
||||
If you want use a version of ``gcc`` or ``g++`` other than the default
|
||||
version on your system, you need to use either the ``-gcc-name``
|
||||
or ``-gxx-name`` compiler option to specify the path to the version of
|
||||
``gcc`` or ``g++`` that you want to use."
|
||||
|
||||
-- `Intel Reference Guide <https://software.intel.com/en-us/node/522750>`_
|
||||
|
||||
Intel compilers may therefore be configured in one of two ways with
|
||||
Spack: using modules, or using compiler flags.
|
||||
|
|
@ -556,11 +559,6 @@ configuration in ``compilers.yaml`` illustrates this technique:
|
|||
Command Line Configuration
|
||||
""""""""""""""""""""""""""
|
||||
|
||||
. warning::
|
||||
|
||||
As of the writing of this manual, added compilers flags are broken;
|
||||
see `GitHub Issue <https://github.com/LLNL/spack/pull/1532>`_.
|
||||
|
||||
One can also control which GCC is seen by the Intel compiler by adding
|
||||
flags to the ``icc`` command:
|
||||
|
||||
|
|
@ -616,7 +614,7 @@ distinguishable by their names. "Old" compilers:
|
|||
Older installations of PGI contains just the old compilers; whereas
|
||||
newer installations contain the old and the new. The new compiler is
|
||||
considered preferable, as some packages
|
||||
(``hdf4``) will not build with the old compiler.
|
||||
(``hdf``) will not build with the old compiler.
|
||||
|
||||
When auto-detecting a PGI compiler, there are cases where Spack will
|
||||
find the old compilers, when you really want it to find the new
|
||||
|
|
@ -641,7 +639,7 @@ Other issues:
|
|||
|
||||
.. note::
|
||||
|
||||
It is believed the problem with ``hdf4`` is that everything is
|
||||
It is believed the problem with HDF 4 is that everything is
|
||||
compiled with the ``F77`` compiler, but at some point some Fortran
|
||||
90 code slipped in there. So compilers that can handle both FORTRAN
|
||||
77 and Fortran 90 (``gfortran``, ``pgfortran``, etc) are fine. But
|
||||
|
|
@ -653,9 +651,40 @@ Other issues:
|
|||
NAG
|
||||
^^^
|
||||
|
||||
At this point, the NAG compiler is `known to not
|
||||
work<https://github.com/LLNL/spack/issues/590>`.
|
||||
The Numerical Algorithms Group provides a licensed Fortran compiler. Like Clang,
|
||||
this requires you to set up a :ref:`mixed-toolchains`. It is recommended to use
|
||||
GCC for your C/C++ compilers.
|
||||
|
||||
The NAG Fortran compilers are a bit more strict than other compilers, and many
|
||||
packages will fail to install with error messages like:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Error: mpi_comm_spawn_multiple_f90.f90: Argument 3 to MPI_COMM_SPAWN_MULTIPLE has data type DOUBLE PRECISION in reference from MPI_COMM_SPAWN_MULTIPLEN and CHARACTER in reference from MPI_COMM_SPAWN_MULTIPLEA
|
||||
|
||||
In order to convince the NAG compiler not to be too picky about calling conventions,
|
||||
you can use ``FFLAGS=-mismatch`` and ``FCFLAGS=-mismatch``. This can be done through
|
||||
the command line:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ spack install openmpi fflags=\"-mismatch\"
|
||||
|
||||
Or it can be set permanently in your ``compilers.yaml``:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- compiler:
|
||||
modules: []
|
||||
operating_system: centos6
|
||||
paths:
|
||||
cc: /soft/spack/opt/spack/linux-x86_64/gcc-5.3.0/gcc-6.1.0-q2zosj3igepi3pjnqt74bwazmptr5gpj/bin/gcc
|
||||
cxx: /soft/spack/opt/spack/linux-x86_64/gcc-5.3.0/gcc-6.1.0-q2zosj3igepi3pjnqt74bwazmptr5gpj/bin/g++
|
||||
f77: /soft/spack/opt/spack/linux-x86_64/gcc-4.4.7/nag-6.1-jt3h5hwt5myezgqguhfsan52zcskqene/bin/nagfor
|
||||
fc: /soft/spack/opt/spack/linux-x86_64/gcc-4.4.7/nag-6.1-jt3h5hwt5myezgqguhfsan52zcskqene/bin/nagfor
|
||||
flags:
|
||||
fflags: -mismatch
|
||||
spec: nag@6.1
|
||||
|
||||
---------------
|
||||
System Packages
|
||||
|
|
@ -663,7 +692,7 @@ System Packages
|
|||
|
||||
Once compilers are configured, one needs to determine which
|
||||
pre-installed system packages, if any, to use in builds. This is
|
||||
configured in the file `~/.spack/packages.yaml`. For example, to use
|
||||
configured in the file ``~/.spack/packages.yaml``. For example, to use
|
||||
an OpenMPI installed in /opt/local, one would use:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -824,8 +853,8 @@ appeal to the system's package manager can fix such problems. If not,
|
|||
the solution is have Spack install the required packages, and then
|
||||
have Spack use them.
|
||||
|
||||
For example, if `curl` doesn't work, one could use the following steps
|
||||
to provide Spack a working `curl`:
|
||||
For example, if ``curl`` doesn't work, one could use the following steps
|
||||
to provide Spack a working ``curl``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -860,7 +889,7 @@ source code, and to load generated environment modules: ``curl``,
|
|||
|
||||
As long as the user's environment is set up to successfully run these
|
||||
programs from outside of Spack, they should work inside of Spack as
|
||||
well. They can generally be activated as in the `curl` example above;
|
||||
well. They can generally be activated as in the ``curl`` example above;
|
||||
or some systems might already have an appropriate hand-built
|
||||
environment module that may be loaded. Either way works.
|
||||
|
||||
|
|
@ -905,6 +934,7 @@ your Linux distribution does not have Environment Modules, you can get it
|
|||
with Spack:
|
||||
|
||||
#. Consider using system tcl (as long as your system has Tcl version 8.0 or later):
|
||||
|
||||
#) Identify its location using ``which tclsh``
|
||||
#) Identify its version using ``echo 'puts $tcl_version;exit 0' | tclsh``
|
||||
#) Add to ``~/.spack/packages.yaml`` and modify as appropriate:
|
||||
|
|
|
|||
|
|
@ -61,11 +61,11 @@ def cxx11_flag(self):
|
|||
# options with '-Wl,-Wl,,'
|
||||
@property
|
||||
def f77_rpath_arg(self):
|
||||
return '-Wl,-Wl,,-rpath,'
|
||||
return '-Wl,-Wl,,-rpath,,'
|
||||
|
||||
@property
|
||||
def fc_rpath_arg(self):
|
||||
return '-Wl,-Wl,,-rpath,'
|
||||
return '-Wl,-Wl,,-rpath,,'
|
||||
|
||||
@classmethod
|
||||
def default_version(self, comp):
|
||||
|
|
|
|||
Loading…
Reference in a new issue