Fujitsu compilers used with the GNU compatibility option (-Xg)
do not yet support all the gnu flags (e.g. -pedantic) and that can
cause the linker (and hence configure) crash.
Fujitsu compilers are identified by the __FUJITSU macro.
This adds a check at `make install` time to look for common symbols. It
attempts to ignore "Fortran-shaped" symbols by default. It also will
look in the source tree for any files named "common_sym_whitelist" and
will ignore any symbols listed in that file (one per line, comments
allowed).
See open-mpi/ompi#375 for more background.
== Short version
Do not export special variables into the environment (e.g., LIBS,
LDFLAGS, etc.) when invoking subdir configure scripts. This prevents
problems described in open-mpi/ompi#471.
== More detail
Exporing special env variables before invoking a subdir configure
script causes problems in some cases. E.g., in open-mpi/ompi#471,
when the user configures with `--with-hwloc=/path/to/hwloc`, and that
directory is *not* in a default linker search location will cause the
libevent subdir configuration to fail.
This happens because:
1. We'll pass LIBS="-L/path/to/hwloc/lib -lhwloc" to the libevent
configure script
1. Meaning: configure-generated executables will link successfully
1. But unless LD_LIBRARY_PATH (or some other
tell-the-linker-where-to-find-things mechanism) includes
/path/to/hwloc/lib, the executable can't run.
Specifically, the libevent "hey, does the compiler generate proper
executables?" check will fail, and configure will abort (because OMPI
needs libevent).
I checked the history: exporting these vars dates all the way back to
LAM/MPI. I can't think of a reason why we need to export these
variables -- AC_CONFIG_SUBDIRs doesn't do it; subdir configure scripts
should be orthogonal from the upper-layer configure script (and its
variables). So let's remove these export statements and see if
anything breaks.
Some versions of clang (at least >= 3.5 -- perhaps older versions,
too?) will *warn* about -finline-functions, but still allow it. This
is very annoying, so check for that warning, too.
Per discussion on devel
(http://www.open-mpi.org/community/lists/devel/2015/02/17030.php), and
per Autoconf 2.69 docs, use the recommended AC_SEARCH_LIBS instead of
AC_CHECK_LIB (e.g., for functions that appear in libc on some
platforms and in a specific library on other platforms).
Use of this configuration option can cause crashing, hanging, and
(worse) incorrect results when btl/sm, btl/scif, or btl/vader are
in use. We discussed this at the January 2015 developers meeting
and it was decided to remove the option entirely. This commit does
just that. All usage of OPAL_WANT_SMP_LOCKS has been removed.
Honestly, a bunch of this code could use similar treatment (i.e.,
AC_DEFUN a template that can be used for OPAL/ORTE/OMPI). However, I
don't quite have time for this today. Exercise left for the future reader...
The RPATH support added a @{libdir} token into
<package>_WRAPPER_EXTRA_LDFLAGS. However, these flags are also
substituted into the pkg-config data files, and they don't understand
the @{foo} notation. So convert @{libdir} into ${libdir}, which
pkg-config *does* understand.
Thanks to Christoph Junghans (@junghans) for notifying us of the issue.
Fixes#406.
It used to be important to get the latest config.sub and config.guess
from upstream because architectures were changing rapidly, and the GNU
Autotools released super-slowly.
However, architectures have not been changing nearly as fast -- the
versions of config.guess and config.sub that ship in the GNU Autotools
are fine. So let's stop getting upstream config.guess|sub from
upstream as part of "make dist".
per several reports on the devel ML, the opal_lifo test hangs
with intel icc 14.0.0.080 (aka 2013sp1) and intel icc 14.0.1.106 (aka 2013sp1u1).
/* older and more recents compilers work fine
* buggy compilers work also fine but only with -O0 */
