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 */
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
Before this commit we checked if the compiler supported compare-and-exchange
on 128-bit values. This turned out to be insufficient. This commit strengthens
the check to see if the processor supports the instruction (or built-in). This
check will not work when cross-compiling (will always disable the 128-bit
atomic) so overrides have been added for this case.
1. Ensure to override CFLAGS properly. Move the setting of CFLAGS outside the AM_CONDITIONAL so that Automake doesn't get confused (because CFLAGS is already set inside an AM_CONDITIONAL -- moving it outside the conditional ensure that this local CFLAGS override trumps all other CFLAGS overrides).
2. Only build libfabric on Linux. Add a little more configury to ensure that we only try to build libfabric on Linux.
3. Remove a dead/unused file
4. Fix typo in condition check
5. Use "false", not "/bin/false"
This commit represents the conversion of the usnic BTL from verbs to
libfabric.
For the moment, libfabric is embedded in Open MPI (currently in the
usnic BTL). This is because the libfabric API is still changing, and
also has not yet been released. Ultimately, this embedded copy of
libfabric will likely disappear and the usnic BTL will rely on an
external installation of libfabric.
New configure options:
* --with-libfabric: will cause configure to fail if libfabric support
cannot be built
* --without-libfabric: will prevent libfabric support from being built
* --with-libfabric=DIR: use an external libfabric installation
* --with-libfabric-libdir=LIBDIR: when paired with --with-libfabric=DIR,
use LIBDIR for the libfabric installation library dir
The --with-libnl3[-libdir] arguments are now gone.
Some versions of gcc require this flag to be set before the __sync
builtin atomic compare and swap will support 128-bit values. If the
flag is required this check adds the flag to the CFLAGS.
A 128-bit compare-and-swap will enable a better atomic lifo implementation
that uses the pointer + counter method to avoid ABA issues. This commit
adds configury to check for the instruction (cmpxchg16b) and adds an
implementation that uses the __int128 type available in C99.
Clean up the orte_check_alps.m4. There was a little of
unnecesary stuff for handling cle 5, since it wasn't actually
doing the right thing, which would be to use pkg-config to
find dependencies both for dynamic and static linking.
Decouple the searching for alps libs, etc. from cray pmi.
Switch the alps ess and alps odls components' config files
to use the ALPS m4 macro.
alps configury fixes
Improve a check for detecting CLE release.
Improve an error message.
Currently only shows whether opal_mca.m4 decides whether to build a
component or not. This will be helpful in debugging a remote user's
setup that somehow, mysteriously decides not to build a specific
component.
Change the CPPFLAGS to just -I$srcdir, and change the include file to
check to be just opal/libltdl/ltdl.h. Do this because the CPPFLAGS
are passed to the preprocessor, and the C program that is passed
through the preprocessor is basically:
#include <opal/libltdl/ltdl.h>
Using the proper -I covers both VPATH and non-VPATH cases.
The mixing of the Slurm PMI and Cray PMI configure was getting
messy and dangerous - developers working on Slurm PMI often don't
have access to Cray PMI, etc.
This mod pulls out the Cray PMI configure into a separate m4 file.
Cray pmi is now configured as follows:
1) on Cray CLE 5 and higher, Cray PMI is auto detected. pkg-config
is used to resolve the necessary CPP flags, link flags and libs,
etc. Nothing needs to be added to the configure line to pick up
Cray PMI.
2) on legacy Cray CLE 4 systems with PMI 4.X, Cray PMI is also
auto detected.
3) on legacy Cray CLE 4 systems with PMI 5.X Cray PMI can't be auto-detected
owing to changes in the PMI pkg-config file which result in pkg-config
returning an error owing to a dependency of PMI on newer versions of ALPS
installs that are not present on CLE 4. So, for those falling in to this
situation, the --with-cray-pmi=(DIR) method needs to be used.
DIR specifies the Cray PMI install directory. The configure file looks
for required alps libraries first in /usr/lib/alps, then in
/opt/cray/xe-sysroot/default/usr/lib/alps.
In OMPI 1.8 and 1.8.1, we didn't allow gfortran to use the ignore-TKR
style "mpi" Fortran module (which is written in Fortran). Instead,
gfortran used the TKR style "mpi" module, which is written in C.
In OMPI 1.8.2, we removed the gfortran restriction (for suitably
modern gfortran -- i.e., >= 4.9). This allowed gfortran to use the
ignore-TKR style "mpi" module, but exposed a bug where MPI Fortran
sentinel values wouldn't be linked properly on OS X. The solution is
to use ```-Wl,-flat_namespace``` (see the OS X ld(1) man page for
details) when both building the libraries and in the wrapper
compilers.
Thanks to Github user yafshar for rasising the issue.
Fixes#259.
Per #257, the configure test used to check:
```c
```
But out in the code base, we actually do this:
```c
// ...
```
This commit updates the configure test to ```#define``` a string and
then use that with the various ident strategies.
Fixes#257
There is a continued interest in being able to do static
linking of executables. When using pkg-config to determine
linking requirements, the default behavior is to only
specify libraries required for dynamic linking.
In many cases, it suffices even for static linking to
use
pkg-config --libs package
to obtain the linkage string required for ld. However, for
libraries that have dependencies on non-standard libraries,
this may not be the case. The cray PMI library is such a case.
On a Cray CLE 5.X system, for example
pkg-config --libs cray-pmi
returns a string like
-L/opt/cray/pmi/5.0.2-1.0000.9906.117.2.ari/lib64 -lpmi
whereas
pkgconfig --static --libs cray-pmi
returns a string (modified for git commits) like
-L/opt/cray/pmi/5.0.2-1.0000.9906.117.2.ari/lib64
-L/opt/cray/ugni/5.0-1.0000.8563.255.10.ari/lib64
-L/opt/cray/alps/6.0.0-2.0000.8544.102.21.ari/lib64
-L/opt/cray/wlm_detect/1.0-1.0000.48964.8.2.ari/lib64
-L/opt/cray/rca/1.0.0-2.0000.49383.133.60.ari/lib64
-lpmi -lpthread -lalpslli -lpthread -lwlm_detect
-lugni -lpthread -lalpsutil -lpthread -lrca
Unfortunately the pkg.m4 does not contain a function for adding
the --static option to PKG_CHECK_MODULES. This commit defines
a new function, PKG_CHECK_MODULES_STATIC, which in addition to
defining the $1_CFLAGS and $1_LIBS variables defined by PKG_CHECK_MODULES,
also defines a $1_STATIC_LIBS.
We must also set the static library filenames properly (i.e., obey the
$FRAMEWORK_LIB_PREFIX that was set). Hence, set the prefixes earlier
in configure.ac, and update OPAL_MCA to set the static library names
properly.
These two macros set the MCA prefix and MCA cmd line id,
respectively. Specifically, MCA parameters will be named
PREFIX<foo> in the environment, and the cmd line will use
-ID foo bar.
These macros must be called during configure.ac and a value
supplied. In the case of Open MPI, the values given are
PREFIX=OMPI_MCA_ and ID=mca.
Other projects (such as ORCM) will call these macros with
their own unique values. For example, ORCM uses PREFIX=ORCM_MCA_
and ID=omca
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running OMPI applications under ORCM, we need the MCA params passed
to the ORCM daemons to be separated from those recognized by the OMPI application.
These two macros set the prefix for the OPAL and ORTE libraries,
respectively. Specifically, the OPAL library will be named
libPREFIXopen-pal.la and the ORTE library will be named
libPREFIXopen-rte.la.
These macros must be called, even if the prefix argument is empty.
The intent is that Open MPI will call these macros with an empty
prefix, but other projects (such as ORCM) will call these macros with
a non-empty prefix. For example, ORCM libraries can be named
liborcm-open-pal.la and liborcm-open-rte.la.
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running MPI applications under ORTE, if the ORTE and OPAL
libraries between OMPI and ORCM are not identical (which, because they
are released at different times, are likely to be different), we need
to ensure that the OMPI applications link against their ORTE and OPAL
libraries, but the ORCM executables link against their ORTE and OPAL
libraries.
This commit makes the folowing changes:
- Add support for the knem single-copy mechanism. Initially vader will only
support the synchronous copy mode. Asynchronous copy support may be added
int the future.
- Improve Linux cross memory attach (CMA) when using restrictive ptrace
settings. This will allow Open MPI to use CMA without modifying the system
settings to support ptrace attach (see /etc/sysctl.d/10-ptrace.conf).
- Allow runtime selection of the single copy mechanism. The default behavior
is to use the best available. The priority list of single-copy mehanisms is
as follows: xpmem, cma, and knem.
- Allow disabling support for kernel-assisted single copy.
- Some tuning and bug fixes.
Update the VERSION file scheme:
* Remove "want_repo_rev".
* Add "tarball_version".
All values are now always included (major, minor, release, greek,
repo_rev). However, configure.ac now runs "opal_get_version.sh
... --tarball", which will return the value of tarball_version (if it
is non-empty) or the "full" version string (i.e.,
"major.minor.releasegreek").
Remove configure.params support: configure.params hasn't been used in
years.
Also remove autogen.subdirs support; those should really be handled by
their respective Makefile.am's.
This is a first cut at updating various infrastructure for git. There
will definitely be more commits; some of the scripts require
committed/pushed code (e.g., the various make-tarball scripts). So
it's not possible to know if we got it right without committing/pushing.
In all previous releases, the version number would be "A.B.C" unless C
was 0, in which case it would be "A.B". This commit changes that
scheme to always be "A.B.C", even if C==0.
Hence, v1.9.0 will be the first release where this new scheme is evident.
This commit was SVN r32816.
It's not enough to AC_COMPILE_IFELSE, do AC_LINK_IFELSE to really make
sure the compiler suite supports it.
Refs trac:4917
This commit was SVN r32802.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
* remove config/ompi_config_solaris_threads.m4 which was dead code
* check if pthreads work "as is" on all platforms including Solaris
(FWIW, the test should have been skipped if Solaris threads are used
and not if configure is ran on a Solaris box)
Refs trac:4911
This commit was SVN r32792.
The following Trac tickets were found above:
Ticket 4911 --> https://svn.open-mpi.org/trac/ompi/ticket/4911
gfortran 4.8 does not support storage_size() on all relevant types
that we need. So add a configure test to check and see if the
compiler's storage_size() intrinsic supports enough types for us to do
MPI_SIZEOF.
Also remove an accidentally redundant check for fortran INTERFACE.
Refs trac:4917
This commit was SVN r32790.
The following Trac tickets were found above:
Ticket 4917 --> https://svn.open-mpi.org/trac/ompi/ticket/4917
1. Fixes according to (http://www.open-mpi.org/community/lists/devel/2014/09/15869.php)
2. Force mpisync:rank0 to gather results. Now sync info is written by rank0 to the output file.
3. Improve mpirun_prof: 1) adopt to the environment (SLURM/TORQUE); 2) recognize some noteset-related mpirun options.
This commit was SVN r32772.
What started as a simple ticket ended up reaching the way up to the
MPI Forum.
It turns out that we are supposed to have MPI_SIZEOF for all Fortran
interfaces: mpif.h, the mpi module, and the mpi_f08 module.
It further turns out that to properly support MPI_SIZEOF, your Fortran
compiler *has* support the INTERFACE keyword and ISO_FORTRAN_ENV. We
can't use "ignore TKR" functionality, because the whole point of
MPI_SIZEOF is that the implementation knows what type was passed to it
("ignore TKR" functionality, by definition, throws that information
away). Hence, we have to have an MPI_SIZEOF interface+implementation
for all intrinsic types, kinds, and ranks.
This commit therefore adds a perl script that generates both the
interfaces and implementations for MPI_SIZEOF in each of mpif.h, the
mpi module, and mpi_f08 module (yay consolidation!).
The perl script uses the results of some new configure tests:
* check if the Fortran compiler supports the INTERFACE keyword
* check if the Fortran compiler supports ISO_FORTRAN_ENV
* find the max array rank (i.e., dimension) that the compiler supports
If the Fortran compiler supports both INTERFACE and ISO_FORTRAN_ENV,
then we'll build the MPI_SIZEOF interfaces. If not, we'll skip
MPI_SIZEOF in mpif.h and the mpi module. Note that we won't build the
mpi_f08 module -- to include the MPI_SIZEOF interfaces -- if the
Fortran compiler doesn't support INTERFACE, ISO_FORTRAN_ENV, and a
whole bunch of ther modern Fortran stuff.
Since MPI_SIZEOF interfaces are now generated by the perl script, this
commit also removes all the old MPI_SIZEOF implementations (which were
laden with a zillion #if blocks).
cmr=v1.8.3
This commit was SVN r32764.
After discussions with Craig, it looks like the check in this
configure test was too aggressive and based on a prior mpi_f08
implementation model. We don't use "value" any more, and we also
don't pass optional parameters back to C code, so this test was
checking far more than it needed to... in a non-standard way (which
breaks in the Intel 2015 Fortran compiler). All we ''really'' need is
to check whether the compiler supports the "optional" keyword. So
make the test ''much'' simpler and just check whether ''optional''
compiles successfull or not.
Reviewed by Craig Rasmussen
cmr=v1.8.3:reviewer=ompi-rm1.8
This commit was SVN r32752.
Replace our old, clunky timing setup with a much nicer one that is only available if configured with --enable-timing. Add a tool for profiling clock differences between the nodes so you can get more precise timing measurements. I'll ask Artem to update the Github wiki with full instructions on how to use this setup.
This commit was SVN r32738.
1. It is not sufficient to put the result of m4_toupper() in a
variable and use that variable as the variable name in
AC_DEFINE_UNQUOTED. Instead, just use m4_toupper() directly in
AC_DEFINE_UNQUOTED. Also, save the result value in a "permanent"
variable that isn't erased, just in case autoconf decides to be lazy
about instantiating the body AC_DEFINE_UNQUOTED and move it later
(this is probably overkill :-) ).
1. Use the OMPI Way of always defining macros (to 0 or 1). Then also
slightly change the logic in util/basename.c to just check
OPAL_HAVE_DIRNAME (because it will always be defined).
Refs trac:4894
This commit was SVN r32723.
The following Trac tickets were found above:
Ticket 4894 --> https://svn.open-mpi.org/trac/ompi/ticket/4894
Based on a patch from Joshua Randall, improve the search for LSF
libraries in orte_check_lsf.m4. This improvement theorhetically
allows the LSF libraries to work in a variety of OSs by properly
searching for its dependent libraries using a variety of library
names.
Fixes trac:4889.
This commit was SVN r32722.
The following Trac tickets were found above:
Ticket 4889 --> https://svn.open-mpi.org/trac/ompi/ticket/4889
The AC_MSG_CHECKING/AC_MSG_RESULT in OPAL_SEARCH_LIBS_CORE were
generating recursive redundant output (i.e., AC_SEARCH_LIBS already
outputs "checking for library containing X... -lY".
Also add the "uppername" logic to OPAL_SEARCH_LIBS_COMPONENT so that
these two macros stay symmetrical.
Refs trac:4894.
This commit was SVN r32721.
The following Trac tickets were found above:
Ticket 4894 --> https://svn.open-mpi.org/trac/ompi/ticket/4894
Make the checks for macro weak symbols be equivalent to the checks for
weak symbols.
Also fix up several OSHMEM configure checks:
* fix an errant AC_MSG_REQUEST
* don't check for profiling ability during configure options checks.
Instead, defer it to later, when we have weak symbol check results.
* don't directly call _FOO macros from the top level
* make setting up OSHMEM profiling similar to MPI profiling: create
OSHMEM_SETUP_PROFILING macro
* cache the results of checking for macro weak symbols (for parity
with the weak symbol check -- although we should really
revisit/audit the whole cache-checking scheme throughout all m4
code; it may well be inconsistently used)
* add some more [] m4 quoting, even in the original C weak symbols test
* style: fix some whitespace errors
Refs trac:4868
This commit was SVN r32590.
The following Trac tickets were found above:
Ticket 4868 --> https://svn.open-mpi.org/trac/ompi/ticket/4868
WHAT: Merge the PMIx branch into the devel repo, creating a new
OPAL “lmix” framework to abstract PMI support for all RTEs.
Replace the ORTE daemon-level collectives with a new PMIx
server and update the ORTE grpcomm framework to support
server-to-server collectives
WHY: We’ve had problems dealing with variations in PMI implementations,
and need to extend the existing PMI definitions to meet exascale
requirements.
WHEN: Mon, Aug 25
WHERE: https://github.com/rhc54/ompi-svn-mirror.git
Several community members have been working on a refactoring of the current PMI support within OMPI. Although the APIs are common, Slurm and Cray implement a different range of capabilities, and package them differently. For example, Cray provides an integrated PMI-1/2 library, while Slurm separates the two and requires the user to specify the one to be used at runtime. In addition, several bugs in the Slurm implementations have caused problems requiring extra coding.
All this has led to a slew of #if’s in the PMI code and bugs when the corner-case logic for one implementation accidentally traps the other. Extending this support to other implementations would have increased this complexity to an unacceptable level.
Accordingly, we have:
* created a new OPAL “pmix” framework to abstract the PMI support, with separate components for Cray, Slurm PMI-1, and Slurm PMI-2 implementations.
* Replaced the current ORTE grpcomm daemon-based collective operation with an integrated PMIx server, and updated the grpcomm APIs to provide more flexible, multi-algorithm support for collective operations. At this time, only the xcast and allgather operations are supported.
* Replaced the current global collective id with a signature based on the names of the participating procs. The allows an unlimited number of collectives to be executed by any group of processes, subject to the requirement that only one collective can be active at a time for a unique combination of procs. Note that a proc can be involved in any number of simultaneous collectives - it is the specific combination of procs that is subject to the constraint
* removed the prior OMPI/OPAL modex code
* added new macros for executing modex send/recv to simplify use of the new APIs. The send macros allow the caller to specify whether or not the BTL supports async modex operations - if so, then the non-blocking “fence” operation is used, if the active PMIx component supports it. Otherwise, the default is a full blocking modex exchange as we currently perform.
* retained the current flag that directs us to use a blocking fence operation, but only to retrieve data upon demand
This commit was SVN r32570.
PGI compilers older that 2013 have a buggy preprocessor
that does not support pragma defined in a macro called
itself called from an other macro
cmr=v1.8.2:reviewer=jsquyres
This commit was SVN r32551.
Unfortunately, I didn't see Dave's review until CMR #4841 went in.
Oops.
This commit is a handful of minor m4 improvements to that original
r32447 commit. It can go to v1.8.3, just to minimize drift between
trunk and v1.8.
Reviewed by Dave Goodell.
cmr=v1.8.3:reviewer=ompi-rm1.8
This commit was SVN r32477.
The following SVN revision numbers were found above:
r32447 --> open-mpi/ompi@c6d9bf906e
In core library portions of the configury (e.g., top-level
configure.ac itself), we were calling AC_CHECK_LIB and
OPAL_CHECK_FUNC_LIB to check for various libraries.
'''SIDENOTE:''' It turns out that modern Autoconf has AC_SEARCH_LIBS,
which does just about exactly what OPAL_CHECK_FUNC_LIB does. So this
commit effectively replaces OPAL_CHECK_FUNC_LIB with AC_SEARCH_LIBS.
However, we never bothered to add these found libraries to the wrapper
compiler list of libraries used for static linking (doh!). We've been
getting lucky for quite a while that components were adding the same
libraries to their wrapper compiler LIBS list.
This is problematic, however, if we don't build some of these
components. For example, Paul Hargrove noticed that if he configured
with --disable-shared --enable-static --disable-io-romio, ROMIO was no
longer adding some libraries to the wrapper LIBS list -- libraries
that just happened to also be needed by core OPAL/ORTE/OMPI layers.
The solution is not to use AC_CHECK_LIB or OPAL_CHECK_FUNC_LIB, but
use a pair of new macros:
* OPAL_SEARCH_LIBS_CORE: a wrapper around AC_SEARCH_LIBS. If we add
something to $LIBS, then also add it to the wrapper list of static
libraries. This is the main piece of functionality that was
wrong/missing.
* OPAL_SEARCH_LIBS_COMPONENT: similar to OPAL_SEARCH_LIBS_CORE, but
instead of directly adding it to the wrapper list of static
libaries, add it to <framework>_<component>_LIBS (which eventually
gets slurped up into the wrapper list of static libraries. See the
lengthy comment in config/opal_setup_wrappers.m4 near the beginning
of OPAL_SETUP_WRAPPER_INIT() for a more detailed explanation).
Most components did this correctly already, but one or two weren't
right, so I implemented this second macro quite similar to the
first and put it everywhere we already used AC_SEARCH_LIBS or
OPAL_CHECK_FUNC_LIB.
This needs to soak for a day or two on the trunk before moving to the
v1.8 branch.
Refs trac:4834
cmr=v1.8.2:reviewer=ggouaillardet
This commit was SVN r32447.
The following Trac tickets were found above:
Ticket 4834 --> https://svn.open-mpi.org/trac/ompi/ticket/4834
