This commit is related to an RFC from June 2014. Disscussion can be
found at:
http://www.open-mpi.org/community/lists/devel/2014/07/15140.php
The finalize function is set using either the linker option -fini or
__attribute__((destructor)) depending on compiler support. I have
confirmed that this hybrid approach works with all the major
compilers. The attribute is supported by gcc, clang, llvm, xlc, and
icc. The fini function will support pgi. If a compiler/linker
combination does not support either the destructor or fini function a
message will be printed on re-init indicating it is not supported (an
improvement over the current behavior-- SEGV).
I moved the following to the destructor function:
- Class system finalize. This solves a bug when MPI_T_finalize is
called before MPI_Init. The only downside to this change is we will
leave the footprint of the opal class system after
MPI_Finalize. This footprint should be relatively small.
This is an alternative to #517 but the two PRs are not
mutually-exclusive (with some modifications). This commit should also
be safe for 1.8.x as it does not change internal or external ABI (#517
changes internal ABI).
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
== 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).
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 */
Some systems have XRC symbols in their libibverbs libraries, but do
not have the appropriate XRC bits in their devel headers (cough cough
RHEL 6.5 libibverbs-rocee-*.x86-64.rpm cough cough).
So expand the XRC config checks to ensure that we can actually find
one of the XRC constants that we need to compile XRC code before
ruling that we can actually build XRC support.
Use the pkg-config related m4 functions to find out where
Cray's xpmem.h and libxpmem are located on a system.
With this commit, there is no longer any need to have to
explicitly indicate an xpmem install location on the configure
line, at least for Cray systems running CLE 4.X and 5.X.
Turns out the OPAL_FLAGS_UNIQ function was chopping
off multiple instances of --param when set in the
CFLAGS. This can happen when -mnative or other machine
target is specified as part of CFLAGS.
Thanks to QuesarVII for reporting this and supplying a patch.
Fixes#324
