[mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2b1-65-geb0e771
Service Account
noreply at mpich.org
Tue Apr 14 23:18:01 CDT 2015
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "MPICH primary repository".
The branch, master has been updated
via eb0e7712de7e0d01c4c94b71ea88ae1ef6ac9a46 (commit)
from 5d4128f8f7ea831ab591f27bee61dc826b002454 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://git.mpich.org/mpich.git/commitdiff/eb0e7712de7e0d01c4c94b71ea88ae1ef6ac9a46
commit eb0e7712de7e0d01c4c94b71ea88ae1ef6ac9a46
Author: Min Si <msi at il.is.s.u-tokyo.ac.jp>
Date: Tue Apr 14 13:31:47 2015 -0500
Fixed the Fortran common symbol issue on Mac.
The linker on Darwin does not allow common symbols, thus libtool adds
the -fno-common option by default for shared libraries. However, the
common symbols defined in different shared libraries and object files
still can not be treated as the same symbol.
For example:
with gfortran, the same common block in the shared libraries and the
object files will have different memory locations separately;
with ifort, the same common block in different shared libraries will get
the same memory location but still get a different location in the
object file.
The -Wl,-commons,use_dylibs option asks linker to check dylibs for
definitions and use them to replace tentative definitions(commons) from
object files, thus it solves the issue of the common symbol mismatch
between the object file and the dylibs (i.e., by setting the address of
a common symbol to the place located in the first dylib that is linked
with the object file and contains this symbol). It needs to be added
only in the linking stage for the final executable file.
The -flat-namespace option allows linker to unify the same common
symbols in different dylibs. It needs to be added in linking stage for
both the shared library and the final executable file.
(see man ld for their definition)
Although gfortran works fine by only adding -flat-namespace, and ifort
works by only adding -Wl,-commons,use_dylibs, we should add both options
here as a generic solution to make sure everything safe.
Signed-off-by: Ken Raffenetti <raffenet at mcs.anl.gov>
diff --git a/configure.ac b/configure.ac
index 0af4994..8279397 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6000,6 +6000,36 @@ if test "X$enable_shared" = "Xyes" ; then
AS_CASE([$host],
[*-*-darwin*],
[
+
+ # The linker on Darwin does not allow common symbols, thus libtool
+ # adds the -fno-common option by default for shared libraries.
+ # However, the common symbols defined in different shared libraries
+ # and object files still can not be treated as the same symbol.
+ # For example:
+ # with gfortran, the same common block in the shared libraries and
+ # the object files will have different memory locations separately;
+ # with ifort, the same common block in different shared libraries
+ # will get the same memory location but still get a different location
+ # in the object file.
+
+ # The -Wl,-commons,use_dylibs option asks linker to check dylibs for
+ # definitions and use them to replace tentative definitions(commons)
+ # from object files, thus it solves the issue of the common symbol
+ # mismatch between the object file and the dylibs (i.e., by setting
+ # the address of a common symbol to the place located in the first
+ # dylib that is linked with the object file and contains this symbol).
+ # It needs to be added only in the linking stage for the final
+ # executable file.
+
+ # On the other hand, the -flat-namespace option allows linker to
+ # unify the same common symbols in different dylibs. It needs to be
+ # added in linking stage for both the shared library and the final
+ # executable file.
+
+ # Although gfortran works fine by only adding -flat-namespace, and
+ # ifort works by only adding -Wl,-commons,use_dylibs, we should add
+ # both options here as a generic solution to make sure everything safe.
+
# sanity check that -Wl,-flat_namespace works on darwin, unless the user
# asked us not to add it
if test "X$enable_two_level_namespace" = "Xno"; then
@@ -6027,31 +6057,28 @@ if test "X$enable_shared" = "Xyes" ; then
# We only need to bother with -Wl,-commons,-use_dylibs if we are
# building fortran bindings (no common block usage in our C libs).
if test "X$enable_f77" = "Xyes" ; then
- # We also don't need this argument if flat_namespace is used.
- if test "X$enable_two_level_namespace" != "Xno" ; then
- # TODO, move this into a PAC macro with real autoconf caching
- pac_cv_wl_commons_use_dylibs_works=no
- AC_MSG_CHECKING([if the F77 compiler accepts -Wl,-commons,use_dylibs])
- AC_LANG_PUSH([Fortran 77])
- PAC_PUSH_FLAG([LDFLAGS])
- PAC_APPEND_FLAG([-Wl,-commons,use_dylibs], [LDFLAGS])
- AC_LINK_IFELSE([AC_LANG_PROGRAM([],[ INTEGER i])],
- [AC_MSG_RESULT([yes])
- pac_cv_wl_commons_use_dylibs_works=yes],
- [AC_MSG_RESULT([no])])
- PAC_POP_FLAG([LDFLAGS])
- AC_LANG_POP([Fortran 77])
-
- # Add the flag to the WRAPPER_LDFLAGS, since this common block issue
- # is really only a problem for dynamically linked user programs.
- #
- # Technically we may not be able to use the same form of the argument
- # for all four compilers (CC/CXX/F77/FC). But we only think this is
- # necessary for Darwin for now, so this unconditional, single-var
- # approximation will work for now.
- if test "X$pac_cv_wl_commons_use_dylibs_works" = "Xyes" ; then
- PAC_APPEND_FLAG([-Wl,-commons,use_dylibs], [WRAPPER_LDFLAGS])
- fi
+ # TODO, move this into a PAC macro with real autoconf caching
+ pac_cv_wl_commons_use_dylibs_works=no
+ AC_MSG_CHECKING([if the F77 compiler accepts -Wl,-commons,use_dylibs])
+ AC_LANG_PUSH([Fortran 77])
+ PAC_PUSH_FLAG([LDFLAGS])
+ PAC_APPEND_FLAG([-Wl,-commons,use_dylibs], [LDFLAGS])
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([],[ INTEGER i])],
+ [AC_MSG_RESULT([yes])
+ pac_cv_wl_commons_use_dylibs_works=yes],
+ [AC_MSG_RESULT([no])])
+ PAC_POP_FLAG([LDFLAGS])
+ AC_LANG_POP([Fortran 77])
+
+ # Add the flag to the WRAPPER_LDFLAGS, since this common block issue
+ # is really only a problem for dynamically linked user programs.
+ #
+ # Technically we may not be able to use the same form of the argument
+ # for all four compilers (CC/CXX/F77/FC). But we only think this is
+ # necessary for Darwin for now, so this unconditional, single-var
+ # approximation will work for now.
+ if test "X$pac_cv_wl_commons_use_dylibs_works" = "Xyes" ; then
+ PAC_APPEND_FLAG([-Wl,-commons,use_dylibs], [WRAPPER_LDFLAGS])
fi
fi
]
-----------------------------------------------------------------------
Summary of changes:
configure.ac | 77 +++++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 52 insertions(+), 25 deletions(-)
hooks/post-receive
--
MPICH primary repository
More information about the commits
mailing list