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
The _strdup usage in opal/util/basename looks like it was a product of
Windows compatibility (see r11336), which we don't care about any
more. Further, opal/win32/win_compat.h, which we sitll maintain for
cygwin compatibility, #define's strdup to _strdup (which is what
Microsoft wants you to use).
So this old _strdup in opal/util/basename.c (and its corresponding
check in configure.ac) should just be removed.
This commit was SVN r32450.
The following SVN revision numbers were found above:
r11336 --> open-mpi/ompi@a28b025150
r32449 --> open-mpi/ompi@d5a3448b8b
Fix parameter order in OPAL_SEARCH_LIBS_CORE call
cmr=v1.8.2:ticket=trac:4841
This commit was SVN r32448.
The following Trac tickets were found above:
Ticket 4841 --> https://svn.open-mpi.org/trac/ompi/ticket/4841
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
Don't use "ompi" names with top-level constructs, because the OMPI
project may not be built. Instead, just use "opal" names -- they'll
always be there.
This commit was SVN r32446.
http://www.open-mpi.org/community/lists/devel/2014/05/14822.php
Revamp the ORTE global data structures to reduce memory footprint and add new features. Add ability to control/set cpu frequency, though this can only be done if the sys admin has setup the system to support it (or you run as root).
This commit was SVN r31916.
top_ompi_srcdir -> OMPI_TOP_SRCDIR
top_ompi_builddir -> OMPI_TOP_BUILDDIR
We also split the srcdir/builddir flags according to their local tree (e.g., OPAL_TOP_SRCDIR), and tied them all together in configure.ac. Renamed ompi_ignore and ompi_unignore to be opal_<foo> as these are agnostic markers.
Only thing left is ompilibdir being treated similar to what we dif for srcdir/builddir. Coming soon.
This commit was SVN r31678.
- This line, and those below, will be ignored--
M opal/mca/event/libevent2021/configure.m4
M opal/mca/hwloc/hwloc172/configure.m4
M configure.ac
M config/opal_setup_libltdl.m4
M config/opal_check_visibility.m4
M config/opal_setup_cc.m4
This commit was SVN r31637.
Nothing is generated in this file; this commit essentially just
renames ompi_config.h.in -> ompi_config.h.
cmr=v1.8.1:reviewer=dgoodell
This commit was SVN r31395.
To accompany r31092 and r310924, also ensure to create a new process
group in the child right after the orted forks. Add trivial configury
to ensure that we have setpgid, and only do the setpgid/getpgid if we
have setpgid.
Without this commit, killing the entire process group can do
unexpected things (e.g., kill the orted, mpirun, and even mpirun's
parent!).
cmr=v1.7.5:reviewer=rhc
This commit was SVN r31132.
The following SVN revision numbers were found above:
r31092 --> open-mpi/ompi@99c9ecaed0
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r310924
* Fixed the AC_ARG_ENABLE for the oshmem option.
* Fixed the AM_CONDITIONALs values for the projects.
* Re-added (and slightly simplified) the use of PROJECT_OSHMEM in
various Makefile.am's to disable building OSHMEM stuff
Submitted by Jeff, reviewed and approved by Ralph.
cmr=v1.7.5:reviewer=ompi-gk1.7
This commit was SVN r31062.
NOTE: I transferred the oshmem-disabled-by-default from the 1.7 branch to the trunk to minimize future disruption if/when we change that option.
cmr=v1.8:reviewer=jsquyres
This commit was SVN r31006.
- Move the ptrdiff_t tests up higher in configure.ac to be with the
rest of the type tests.
- Create new OMPI_FIND_MPI_AINT_COUNT_OFFSET for finding the
corresponding types of MPI_Aint, MPI_Count, and MPI_Offset.
Consolidate all the old C and Fortran tests into this new macro (and
.m4 file).
- Fix Fortran MPI_*_KIND tests that incorrectly keyed off assumed
types (e.g., int64_t) rather than whatever the corresponding C
MPI_Aint, MPI_Count, MPI_Offset types turned out to be.
- Add new logic to ensure that sizeof(MPI_Count) <= sizeof(size_t),
because our entire PML, BTL, and convertor infrastructure requires
this. As a side effect, just like MPI_Offset the same type of
MPI_Count (because MPI_Count has to be able to hold an MPI_Offset,
so we can't let MPI_Offset be larger than a MPI_Count).
This commit was SVN r30776.
The following Trac tickets were found above:
Ticket 4205 --> https://svn.open-mpi.org/trac/ompi/ticket/4205
fix the case, to enable oshmem-fortran when "with-shmem" was specified and "ompi-fortran" was enabled and happy.
fixed by Roman, reviewed by Miked
Refs trac:3763
This commit was SVN r30391.
The following Trac tickets were found above:
Ticket 3763 --> https://svn.open-mpi.org/trac/ompi/ticket/3763
The check to enable shmem fortran was too early, MPI can disable fortran but SHMEM fortran check was already done.
Refs trac:3763
This commit was SVN r30340.
The following Trac tickets were found above:
Ticket 3763 --> https://svn.open-mpi.org/trac/ompi/ticket/3763
weren't building the MPI C++ bindings because this causes "CXX=no" to
be passed to the mpicxx wrapper compiler.
Unfortunately, this optimization was brought to the v1.7 branch, and
therefore if you --disable-mpi-cxx on the v1.7 branch, the same
problem will happen. So this needs to be CMR'ed to v1.7 as well.
Submitted by Jeff, reviewed by Brian. RM approved by Brian.
Fixes trac:4120.
cmr=v1.7.4:reviewer=ompi-gk1.7:subject=Fix mpicxx wrapper compiler
This commit was SVN r30302.
The following Trac tickets were found above:
Ticket 4120 --> https://svn.open-mpi.org/trac/ompi/ticket/4120
* Fix some typos in macro names.
* Add case for OS's that have statfs() but no struct statfs (!).
* Add case for NetBSD with struct statvfs.f_fstypename.
Many thanks to Paul Hargrove who developed the majority of this patch.
Reviewed by Jeff Squyres.
cmr=v1.7.4:reviewer=ompi-rm1.7
This commit was SVN r30255.
As noted by Paul Hargrove, the #if's surrounding the use of statfs()
and statvfs() in opal/util/path.c have apparently gotten stale (e.g.,
modern flavors of *BSD OSs no longer define __BSD). Changes:
* Add statfs and statvfs to the AC_CHECK_FUNCS in configure.ac
* Add a sanity check to ensure that we have at least one of statfs()
or statvfs(). Add a similar sanity check in opal/util/path.c, just
as defensive programming.
* Use AC_CHECK_MEMBERS in configure.ac to check for specific struct
statfs/struct statvfs members that we use in opal/util/path.c
* In path.c, add some #includes as listed on the OS man page for
statfs(2) (OS X 10.8.5/Mountain Lion)
* The previous code used statvfs() on Solaris and statfs() everywhere
else. Attempting to replicate this with behavior-based configure
testing led to fairly complicted if/else logic, so the new code
uses whichever of the two are available (i.e., it might actually
use both -- OS X 10.8.5 and RHEL 6.5 have both statfs() and
statvfs()). The rationale here is that we don't really care which
of the two functions report the answer; we'll take the answer
regardless of where it comes from. For example, if one function
returns a failure and the other does not, we'll use the results
from the successful function and ignore the failed one.
This new code seems to work on OS X and Linux. We'll have to see what
happens with MTT and future Paul Hargrove testing...
cmr=v1.7.4:reviewer=ompi-rm1.7:subject=Make statfs/statvfs more robust
This commit was SVN r30198.
pkg{data,lib,includedir}, use our own ompi{data,lib,includedir}, which is
always set to {datadir,libdir,includedir}/openmpi. This will keep us from
having help files in prefix/share/open-rte when building without Open MPI,
but in prefix/share/openmpi when building with Open MPI.
This commit was SVN r30140.
more:
- Remove OPAL_ENABLE_MULTI_THREADS, since it didn't really do anything
correctly. Opal always has threads enabled at this point.
- Remove OMPI_ENABLE_PROGRESS_THREADS, since this hasn't worked in
8 years and it has performance issues we'll never be able to
overcome. Note that we have plans for re-adding async progress, using
a hybrid protocol of async and sync sends.
- OMPI_ENABLE_THREAD_MULTIPLE now determines whether the thread lock
macros do the check or not.
- Condition variables are ALWAYS polling right now, which fixes the thread
live-lock currently found when THREAD_MULTIPLE is turned on.
This commit was SVN r29891.
This is helpful in the work for #3694: ensure that many places that
eventually end up in configure don't overly-pollute the global shell
variable space (because debugging accidental shell variable pollution
can be a real pain).
Refs trac:3694
This commit was SVN r29830.
The following Trac tickets were found above:
Ticket 3694 --> https://svn.open-mpi.org/trac/ompi/ticket/3694
The chmod action statements need to be put in individual
AC_CONFIG_FILE statements that generate the target file in question.
With the original code, the 2 chmod statements were executed for
''each'' file in the AC_CONFIG_FILES block (resulting in both error
messages before the files were created, and needless chmods after the
files were created).
This commit was SVN r29829.
2. Oshmem examples moved to 'mpi' build target.
3. Oshmem examples renamed as 'shmem' => 'oshmem'.
4. Fixed warnings in oshmem_info.
Refs: 3763
This commit was SVN r29663.
unfortunately the debian packaging files should reside in the root folder
and cannot be placed under contrib/dist/... tree.
developed by Aleksey, reviewed by miked
cmr=v1.7.4:reviewer=ompi-gk1.7
This commit was SVN r29615.
The following common shared libraries did not have versioning:
* ompi/common/ofacm
* ompi/common/verbs
* ompi/common/ugni
Additionally, we still had shared library versions in VERSION for the
following libraries, which no longer exist:
* ompi/common/portals
* opal/common/hwloc
This commit was SVN r29421.
configure-time dynamic allocation of flags. The net result for platforms
which only support BTL-based communication is a reduction of 8*nprocs bytes
per process. Platforms which support both MTLs and BTLs will not see
a space reduction, but will now be able to safely run both the MTL and BTL
side-by-side, which will prove useful.
This commit was SVN r29100.
Add support for MPI_Count type and MPI_COUNT datatype and add the required
MPI-3 functions MPI_Get_elements_x, MPI_Status_set_elements_x,
MPI_Type_get_extent_x, MPI_Type_get_true_extent_x, and MPI_Type_size_x.
This commit adds only the C bindings. Fortran bindins will be added in
another commit. For now the MPI_Count type is define to have the same size
as MPI_Offset. The type is required to be at least as large as MPI_Offset
and MPI_Aint. The type was initially intended to be a ssize_t (if it was
the same size as a long long) but there were issues compiling romio with
that definition (despite the inclusion of stddef.h).
I updated the datatype engine to use size_t instead of uint32_t to support
large datatypes. This will require some review to make sure that 1) the
changes are beneficial, 2) nothing was broken by the change (I doubt
anything was), and 3) there are no performance regressions due to this
change.
Increase the maximum number of predifined datatypes to support MPI_Count
Put common get_elements code to ompi/datatype/ompi_datatype_get_elements.c
Update MPI_Get_count to reflect changes in MPI-3 (return MPI_UNDEFINED when the count is too large for an int)
This commit was SVN r28932.
http://www.open-mpi.org/community/lists/users/2013/02/21356.php and a
helpful tip from Dave Goodell, set the precious variables for
compilers to "no" that we don't want. Libtool's m4 configry will
interpret this as "I won't be using this language; don't bother
setting it up."
This commit was SVN r28047.
flags, and mca flags are kept seperate until the very end. The main configure
wrapper flags should now be modified by using the OPAL_WRAPPER_FLAGS_ADD
macro. MCA components should either let <framework>_<component>_{LIBS,LDFLAGS}
be copied over OR set <framework>_<component>_WRAPPER_EXTRA_{LIBS,LDFLAGS}.
The situations in which WRAPPER CPPFLAGS can be set by MCA components was
made very small to match the one use case where it makes sense.
This commit was SVN r27950.
around OMPI_SETUP_MPI_FORTRAN in r27817 when removing the OPAL hacks for the
no-Fortran case. Then r27821 worked around a build issue caused by
r27817 in a sub-optimal way.
This commit was SVN r27826.
The following SVN revision numbers were found above:
r27817 --> open-mpi/ompi@fc3df11e08
r27821 --> open-mpi/ompi@0ede5be003
OMPI_WANT_FORTRAN_BINDINGS to 0 so that all the Fortran tests that
examine that variable have a numeric value to compare against.
This commit was SVN r27821.
actually care if opal_pointer_array is limited to handle_max already passes
that in as the max_size during init, so don't need it there. The arch
constant was a bit more difficult, so pass that in during MPI init and
leave empty otherwise.
This is to help with the effort to allow building ompi against an external
opal or orte.
This commit was SVN r27817.
to compile. With recent Autoconf versions, AC_CHECK_HEADERS only succeeds
if the header compiles, so need to check these two with sys/param.h
explicitly included in the search list...
This commit was SVN r27715.
* We always build OPAL, so always do the filesystem case-sensitivity
check
* Protect the extra ORTE/OMPI macros with "if we're building this
project..." tests
This commit was SVN r27699.
additional functionality. Rationale (refs trac:3422):
* Normal MPI applications only ever use the MPI API. Hence, -lmpi is
sufficient (they'll never directly call ORTE or OPAL
functions). This is arguably the most common case.
* That being said, we do have some test programs (e.g., those in
orte/test/mpi) that call MPI functions but also call ORTE/OPAL
functions. I've also written the occasional MPI test program that
calls opal_output, for example (there even might be a few tests in
the IBM test suite that directly call ORTE/OPAL functions).
* Even though this is not a common case, these applications should
also compile/link with mpicc.
* So we should add a --openmpi:linkall option that will also link
in whatever is necessary to call ORTE/OPAL functions
* Yes, we could hard-code "-lopen-rte -lopen-pal" in Makefiles, but
we do reserve the right to change those library names and/or add
others someday, so it's better to abstract out the names and let
the wrapper supply whatever is necessary.
* ORTE programs, however, are different. They almost always call OPAL
functions (e.g., if they want to send a message, they must use the
OPAL DSS). As such, it seems like the ORTE programs should always
link in OPAL.
Therefore:
* Add undocumented --openmpi:linkall flag to the wrapper compilers.
See the comment in opal_wrapper.c for an explanation of what it
does. This flag is only intended for Open MPI developers -- not
end users. That's why it's undocumented.
* Update orte/test/mpi/Makefile.am to add --openmpi:linkall
* Make ortecc/ortec++'s wrapper data text files always explicitly
link in libopen-pal
This commit was SVN r27670.
The following SVN revision numbers were found above:
r27668 --> open-mpi/ompi@cf845897aa
The following Trac tickets were found above:
Ticket 3422 --> https://svn.open-mpi.org/trac/ompi/ticket/3422
1. Restore libopen-pal.la, libopen-rte.la, and libmpi.la to be
separate entities (i.e., don't have libopen-rte.la include
libopen-pal.la, and don't have libmpi.la include libopen-pal.la).
Yay!
1. Consequently, make the wrapper compilers look for flags indicating
that the user wants to compile statically (currently: -static,
!--static, -Bstatic, and "-Wl," in front of all of those). If it
is, follow a 6-way matrix for determinining which libraries to
list on the underlying command line.
1. To support that, add the name of a token static and dynamic
library to look for in each of the wrapper compiler data files.
1. Fix a long-standing typo in the opalcc wrapper data file.
This commit was SVN r27662.
- fix the Fortran layer to use new macros to convert Fortran-to-C status
- change the C internals to pull out old OMPI_SET_STATUS* macros
Also, change name of "status" argument in topo_test_f.c to "topo_type".
This commit was SVN r27403.
particularly with respect to threading flags.
Before this change, the following scenario would fail (e.g., on Linux
with pthreads):
{{{
$ ./configure --disable-shared --enable-static ...
$ make clean install
$ cd examples
$ make clean all
}}}
Linking the Fortran examples would fail with missing pthread symbols.
This commit was SVN r26927.
