NAG Fortran compiler configury issue

[jsquyres]

As reported by @PHHargrove in http://www.open-mpi.org/community/lists/devel/2016/01/18470.php, we should fix the configury for the NAG Fortran compiler.

This likely will not happen for the v1.10.2 release; marking the milestone for 1.10.3.

[ggouaillardet]

@jsquyres that should resolve the need to hack mpifort-wrapper-data.txt

this patch is for v1.10, could you please review it ?
i will push to master and make the PRs if it is looks good to you.

diff --git a/config/opal_setup_wrappers.m4 b/config/opal_setup_wrappers.m4
index a85e08a..31194db 100644
--- a/config/opal_setup_wrappers.m4
+++ b/config/opal_setup_wrappers.m4
@@ -12,7 +12,7 @@ dnl Copyright (c) 2004-2005 The Regents of the University of California.
 dnl                         All rights reserved.
 dnl Copyright (c) 2006-2010 Oracle and/or its affiliates.  All rights reserved.
 dnl Copyright (c) 2009-2015 Cisco Systems, Inc.  All rights reserved.
-dnl Copyright (c) 2015      Research Organization for Information Science
+dnl Copyright (c) 2015-2016 Research Organization for Information Science
 dnl                         and Technology (RIST). All rights reserved.
 dnl $COPYRIGHT$
 dnl 
@@ -441,6 +441,7 @@ AC_DEFUN([OPAL_SETUP_WRAPPER_FINAL],[
        OMPI_WRAPPER_EXTRA_LIBS="$ompi_mca_wrapper_extra_libs"
        OPAL_FLAGS_APPEND_UNIQ([OMPI_WRAPPER_EXTRA_LIBS], [$wrapper_extra_libs])
        OMPI_WRAPPER_EXTRA_LIBS="$OMPI_WRAPPER_EXTRA_LIBS $with_wrapper_libs"
+       OPAL_FLAGS_APPEND_UNIQ([OMPI_WRAPPER_EXTRA_LIBS], [$LIBS])
        AC_SUBST([OMPI_WRAPPER_EXTRA_LIBS])
        AC_MSG_RESULT([$OMPI_WRAPPER_EXTRA_LIBS])

[PHHargrove]

@ggouaillardet

I can confirm that this patch eliminates the need to add -lpthread to the wrapper data files.
However, I do still need to "hack" them to replace -Wl, with -Wl,-Wl,,.

I cannot comment as to any possible undesired side-effects of your patch (I leave that sort of review to Jeff).

-Paul

[ggouaillardet]

I will have an other patch ready by tomorrow so there is no more need to manually replace -Wl,

about using shared libraries, I identified two issues

1. we must use -Wl,shared instead of -shared
   it seems this is now fixed in libtool 2.4.6 but not in 2.4.2
   (we already patch configure for similar purposes, so I will make a similar fix)
2. -pthread is good for gcc, but not for nagfor (-lpthread should be used here)
   as of now, libopen-pal.la uses -pthread (this is a C only library, so it makes sense)
   but when linking with nagfor, the -pthread option is pulled from libopen-pal.la and linkage fails.
   I did not try yet whether this issue is fixed in libtool, and I am not sure this is really a libtool issue anyway.
   a way to fix that is to ensure the same option is used by CC and FC (and CXX too ?) for pthreads
   (and that would be -lpthread here)

@jsquyres any thoughts ?

[ggouaillardet]

@jsquyres i made #1295 to fix that (both static and shared libs)

regarding the -pthread thing, i chose an other direction.
i patch config/ltmain.sh in order to replace -pthread with -Wl,-pthread

i was not so confident with the previous approach, plus libevent configure sets the -pthread flag, and it would have been a bit intrusive to change its configury.

[rhc54]

@jsquyres Where are we on this?

[ggouaillardet]

@PHHargrove could you please give a try to https://patch-diff.githubusercontent.com/raw/open-mpi/ompi/pull/1295.patch
it should fix everything, except maybe with --disable-mpi-fortran
my NAG eval license has expired, and I have not done much recently

[PHHargrove]

@ggouaillardet
I will give it a try tonight and let you know what I find.

[PHHargrove]

@ggouaillardet 👍

Looks good!
I tried the following two configurations, with both versions 5 and 6 of NAG Fortran

• --enable-debug --prefix=... FC=nagfor
• --enable-debug --prefix=... FC=nagfor --enable-static --disable-shared
• --enable-debug --prefix=... FC=nagfor --disable-mpi-fortran

All six combinations worked as expected.

In case somebody (Jeff?) is keeping track of which Fortan compilers build which bindings:

$ grep 'building Fortran' */LOG/configure.log
openmpi-pr1295-linux-x86_64-nagfor-5/LOG/configure.log:checking if building Fortran mpif.h bindings... yes
openmpi-pr1295-linux-x86_64-nagfor-5/LOG/configure.log:checking if building Fortran 'use mpi' bindings... yes
openmpi-pr1295-linux-x86_64-nagfor-5/LOG/configure.log:checking if building Fortran 'use mpi_f08' bindings... no
openmpi-pr1295-linux-x86_64-nagfor-6/LOG/configure.log:checking if building Fortran mpif.h bindings... yes
openmpi-pr1295-linux-x86_64-nagfor-6/LOG/configure.log:checking if building Fortran 'use mpi' bindings... yes
openmpi-pr1295-linux-x86_64-nagfor-6/LOG/configure.log:checking if building Fortran 'use mpi_f08' bindings... no

[adamjstewart]

What's the progress on this issue? It seems to still be present in release 2.0.1. Will this be fixed in the next release? In the meantime, is there a semi-official patch I can use? I'm working on development of the Spack package manager and was hoping to get support for OpenMPI built with NAG.

[rhc54]

Either this has been fixed in v1.10.6, or it will not be fixed in the 1.10 series

[certik]

I can confirm, that the same issue happens with NAG 6.1 and openmpi 2.1.1, when cmake gives an error:

gcc: error: unrecognized command line option ‘-rpath’

and patching mpifort-wrapper-data.txt fixes it.

sed -i.orig -e 's/-Wl,/-Wl,-Wl,,/g' $INSTALL_PREFIX/share/openmpi/mpifort-wrapper-data.txt

So I think this looks like a bug in openmpi.