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.
