2006-10-16 01:21:08 +04:00
|
|
|
# There can be multiple blocks of configuration data, chosen by
|
|
|
|
|
# compiler flags (using the compiler_args key to chose which block
|
|
|
|
|
# should be activated. This can be useful for multilib builds. See the
|
|
|
|
|
# multilib page at:
|
|
|
|
|
# https://svn.open-mpi.org/trac/ompi/wiki/compilerwrapper3264
|
|
|
|
|
# for more information.
|
|
|
|
|
|
2006-01-16 04:48:03 +03:00
|
|
|
project=Open MPI
|
|
|
|
|
project_short=OMPI
|
|
|
|
|
version=@OMPI_VERSION@
|
|
|
|
|
language=C
|
|
|
|
|
compiler_env=CC
|
|
|
|
|
compiler_flags_env=CFLAGS
|
2012-11-20 23:33:14 +04:00
|
|
|
compiler=@WRAPPER_CC@
|
2006-01-16 04:48:03 +03:00
|
|
|
extra_includes=@OMPI_WRAPPER_EXTRA_INCLUDES@
|
|
|
|
|
preprocessor_flags=@OMPI_WRAPPER_EXTRA_CPPFLAGS@
|
2010-09-30 22:33:08 +04:00
|
|
|
compiler_flags_prefix=@OMPI_WRAPPER_EXTRA_CFLAGS_PREFIX@
|
2006-01-16 04:48:03 +03:00
|
|
|
compiler_flags=@OMPI_WRAPPER_EXTRA_CFLAGS@
|
|
|
|
|
linker_flags=@OMPI_WRAPPER_EXTRA_LDFLAGS@
|
2012-12-14 20:34:20 +04:00
|
|
|
# Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we
|
|
|
|
|
# intentionally only link in the MPI libraries (ORTE, OPAL, etc. are
|
|
|
|
|
# pulled in implicitly) because we intend MPI applications to only use
|
|
|
|
|
# the MPI API.
|
2013-01-29 04:00:43 +04:00
|
|
|
libs=-lmpi
|
|
|
|
|
libs_static=-lmpi -lopen-rte -lopen-pal @OMPI_WRAPPER_EXTRA_LIBS@
|
Put back the static-library-detection stuff from r27668, with some
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@cf845897aa89407195aa13f56ddf4ec0d3c21a68
The following Trac tickets were found above:
Ticket 3422 --> https://svn.open-mpi.org/trac/ompi/ticket/3422
2012-12-14 02:31:37 +04:00
|
|
|
dyn_lib_file=libmpi.@OPAL_DYN_LIB_SUFFIX@
|
|
|
|
|
static_lib_file=libmpi.a
|
2006-01-16 04:48:03 +03:00
|
|
|
required_file=
|
2007-04-21 04:16:31 +04:00
|
|
|
includedir=${includedir}
|
|
|
|
|
libdir=${libdir}
|