which case, skip it, since it takes so bloody long to compile)
* Dsiable the XGrid PLS when compiling in 64 bit mode, as Tiger only
ships with XGrid libraries for 32bit apps
* ompi_config.h and orte_config.h (and supporting headers) are now only
installed if --with-devel-headers is enabled. Since they are no
longer needed for MPI applications, it doesn't make sense to install
them if we are only installing mpi.h and mpif.h.
Also, since we are no longer including ompi_config.h in mpi.h, there
is no longer a need to do the dumb sed trick on install
This commit was SVN r7042.
friendly #defines to be included in mpi.h (even for users), such as
_GNU_SOURCE, which can have some really big consequences on Linux.
Instead, add mpi.h to AC_CONFIG_HEADERS and just include the #defines
we have to have for mpi.h and the C++ bindings.
This commit was SVN r7022.
callbacks to be triggered when memory is about to leave the current
process. The system is designed to allow a variety of interfaces,
hopefully including whole-sale replacement of the memory manager,
ld preload tricks, and hooks into the system memory manager. Since
some of these may or may not be available at runtime and we won't know
until runtime, there is a query funtion to look for availability of
such a setup.
* Added ptmalloc2 memory manager replacement code. Not turned on by
default, can be enabled with --with-memory-manager=ptmalloc2.
Only tested on Linux, not even compiled elsewhere. Do not use
on OS X, or you will never see your process again.
* Added AM_CONDITIONAL for threads test to support ptmalloc2's build
system
This commit was SVN r6790.
the values to the PML structure. This will allow PMLs that want to do
hardware matching at the cost of a smaller range of valid tags and cids.
Updated all the places that used the MPI_TAG_UB_VALUE constant to instead
look at the pml struct.
This commit was SVN r6778.
Red Storm. Add stub functions to ompi_config_bottom.h when they are
around
* Add protection for a bunch of #include <netinet/in.h>s
* Fix up the Portals BTL so that it compiles on Red Storm and has the
right mojo for initialization on Red Storm
* Add some important comments to ompi_check_package and mvapi configures
* Add support for platforms without getpwuid() (aka, Red Storm).
This commit was SVN r6478.
- After long discussions and ruminations on how we run components in
LAM/MPI, made the decision that, by default, all components included
in Open MPI will use the version number of their parent project
(i.e., OMPI or ORTE). They are certaint free to use a different
number, but this simplification makes the common cases easy:
- components are only released when the parent project is released
- it is easy (trivial?) to distinguish which version component goes
with with version of the parent project
- removed all autogen/configure code for templating the version .h
file in components
- made all ORTE components use ORTE_*_VERSION for version numbers
- made all OMPI components use OMPI_*_VERSION for version numbers
- removed all VERSION files from components
- configure now displays OPAL, ORTE, and OMPI version numbers
- ditto for ompi_info
- right now, faking it -- OPAL and ORTE and OMPI will always have the
same version number (i.e., they all come from the same top-level
VERSION file). But this paves the way for the Great Configure
Reorganization, where, among other things, each project will have
its own version number.
So all in all, we went from a boatload of version numbers to
[effectively] three. That's pretty good. :-)
This commit was SVN r6344.
* rename ompi_malloc to opal_malloc
* rename ompi_numtostr to opal_numtostr
* start of rename of ompi_environ to opal_environ
This commit was SVN r6332.
* If we are on solaris, don't use the system qsort(), as it appears to be
broken in 64 bit mode on Solaris 8 (there are bugs about this in
SunSolve). Instead, use ompi_qsort(), which is taken from FreeBSD.
A #define in ompi_config_bottom.h makes this invisible to most of the
OMPI source tree.
* Fix memory badness in ompi_progress_register where we were reallocing the
array to be number of elements long instead of number of elements *
sizeof(element). Found while using bcheck to track down our problems in
64 bit on big endian machines.
* The debugging output code in session_dir.c could pass NULL as a value for a %s,
which will turn into "(null)" automagically on glibc, but causes segfaults for
older libcs (like those on Solaris). Check for this case in session_dir.c and
don't pass NULL as a %s value into ompi_output().
* Fix missing header file in convertor.c
This commit was SVN r6186.
- Fully support REAL*N, INTEGER*N, and COMPLEX*N in the MPI_Op
reduction operations.
- Update ddt to fully support these types as well, to include using
the results of sizes and alignments determined by configure
- Discover the goodness of m4 and consolidate a LOT of configure code
(i.e., remove a lot of essentially duplicated code and
m4-subroutine-ize it). The big kicker was figuring out how to
parameterize AC_DEFINE_UNQUOTED, which you can do if you use m4
properly.
- If we don't support a given INTEGER*N, REAL*N, or COMPLEX*N, don't
error. Just set the right flags so that we don't support them in
the MPI layer.
This commit was SVN r5788.
Merged in from:
svn merge -r5448:5496 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5550.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5448
r5496
from:
svn merge -r5440:5448 https://svn.open-mpi.org/svn/ompi/tmp/hetero .
This commit was SVN r5549.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r5440
r5448
- After consulting with George, only define the fortran types if the
back end Fortran compiler actually supports them. We always have
the corresponding global C datatypes, but it seems nicer user
behavior to have them fail at compile time rather than at run time
if they try to use MPI_INTEGER8 and it doesn't exist (in which case
ompi_mpi_integer8 will be a synonym for ompi_mpi_datatype_null)
This commit was SVN r5520.
MPI_COMPLEX*x, and some optional C datatypes in MPI reduction
operations. These types are not technically supported by the letter
of the MPI standard, but are implied by the spirit of it (and there
are definitely users that use them in real applications)
- Add checks in configure for back-end C types for MPI_INTEGER*x and
MPI_REAL*x
- Create C data structs for MPI_COMPLEX*x
- Fixed typo for MPI_INTEGER8 in mpi.h
- Updated configure macros to create MPI_FORTRAN_INTEGER* defines, as
opposed to MPI_FORTRAN_INT, which was causing [me] lots of confusion
(between C "*_INT" names and Fortran "*_INT" names). This caused
some trivial updates in ddt, ompi_info, and the MPI layer to match.
- Update ompi_info to show whether we have each MPI_INTEGER*x,
MPI_REAL*x, and MPI_COMPLEX*x
- Extended reduction operations for optional datatypes:
- "C integer" now includes long long int, long long, and unsigned
long long
- "Fortran integer" now includes MPI_INTEGER*x
- "Floating point" now includes MPI_REAL*x
- "Complex" now includes MPI_COMPLEX*x
This commit was SVN r5511.
Last night's fix completely disregarded building the DSO components,
which need to have the dllimport flag set for all the libmpi stuff, and
need to export their component structures. Unfortunately needed to
add another #define to deal with the components for windows, but
it required the least amount of work for all the non-Windows people.
This commit was SVN r5461.
we are part of the source tree and not defined otherwise, we are going
with an always defined if ompi_config.h is included policy. If
ompi_config.h is included before mpi.h or before OMPI_BUILDING is set,
it will set OMPI_BUILDING to 1 and enable all the internal code that
is in ompi_config_bottom.h. Otherwise, it will only include the
system configuration data (enough for defining the C and C++ interfaces
to MPI, but not perturbing the user environment).
This should fix the problems with bool and the like that the Eclipse
folks were seeing. It also cleans up some build system hacks that
we had along the way.
Also, don't use int64_t as the default size of MPI_Offset, because it
requires us including stdint.h in mpi.h, which is something we really
shouldn't be doing.
And finally, fix a ROMIO Makefile that didn't set -DOMPI_BUILDING=1,
as ROMIO includes mpi.h, but not ompi_config.h
This commit was SVN r5430.
OMPI_ENABLE_DEBUG because that changes the size of struct's (e.g.,
ompi_object) in the unit tests as compared to what may have been
compiled in the library.
This commit was SVN r5373.
ompi_config_bottom.h was a bad place to have it as normally this file is included
before everything else so we always define our own INADDR_NONE generating
a lot of warnings on some OSes.
This commit was SVN r5198.
- Added some protection to portions that should only be used when
we're building OMPI (not, for example, when mpicc is being used to
compile a user's MPI application)
This commit was SVN r5082.
technically speaking, this is a cosmetic change, but having the wrong
parameter names was extremely confusing -- it took me a while (and I
had to cross-reference MPI-1) to figure out that they were wrong, and
I was thinking about the functions incorrectly as a result. Our mpi.h
should have the Right names in order to not confuse users (and
developers!).
This commit was SVN r5034.
This commit was SVN r4978.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r4977
threads (defaults to use MPI threads, disable progress threads). This
allows us to have MPI threaded support, but without progress threads
and all that fun stuff.
This commit was SVN r4443.
- Use fcntl.h, not sys/fcntl.h (man pages on every platform I could find
say fcntl.h and solaris/AIX don't provide sys/fcntl.h)
- Make timeradd macro available on platforms where sys/time.h exists but
timeradd macro doesn't (Solaris)
- Include util/printf.h from ompi_config_bottom.h so that ompi_asprintf
and friends are always available.
This commit was SVN r4441.
are generated at configure time, so there is no need to have them in the
tarball (and doing so can cause some really evil VPATH issues). The .in
files needed to make ompi_config.h and mpif.h are included in the tarball.
This commit was SVN r4367.
#if OMPI_WANT_MPI2_ONE_SIDED and some automake conditionals. Also had
to add some AC_SUBSTs to eliminate part of mpif.h (otherwise the
"external" statements would have made undefined symbols).
All the MPI-2 one-sided functionality (including the skeleton
top-level MPI API functions that only invoke an MPI exception) can be
re-enabled with --enable-mpi2-one-sided.
This commit was SVN r3802.
support is included because ROMIO is inherently thread-unsafe.
One possible way to have true asynchronous progress would be to use a
progress thread that wakes up and polls at some frequency when there
are non-blocking IO requests pending. This is pretty icky, though --
it should definitely have an MCA parameter to enable/disable this
functionality, as well as another to control the polling frequency.
This also strengthens the argument that we need a v2 of the io
framework -- one that is not designed to exclusively support ROMIO --
one that does something unimaginably "better" for the parallel MPI-2
IO interface. :-)
This commit was SVN r3786.
