On Jun 16, 2005, at 7:10 PM, Ben Allan wrote:
The *only* flag that mpicc (and friends) recognizes is --showme.
*Everything* else is passed to the underlying compiler. We didn't
want
to take the chance, for example, that --help was actually a valid flag
for the underlying compiler.
So is this called out in the mpi-2 standard?
Please god let it be so; i haven't noticed it yet if it is.
No. No wrapper compilers are even mentioned in the standard. --showme
is simply a flag that has existed in LAM/MPI for many, many years (a
decade?) and no one has ever complained about it. So we figured it was
"safe enough".
FWIW, the only command that the MPI spec [somewhat] standardizes is
mpiexec.
MPI took a cue from the Fortran standard -- it only defines behavior
after the MPI application is running. It does not define how to create
MPI executables nor how to launch them (with the exception of the
loosely-standardized mpiexec command, added in MPI-2). Those are all
implementation-dependent issues.
This kinda hamstrings the ability to add features into wrapper
compilers, but we can figure out something safe if we need to.
yah. wouldn't it be nice if we could reserve
--mpi-* for the compiler wrapper guys? I'm guessing
there aren't *too many* existing serial compilers that
already use --mpi-$x.
I probably wouldn't be opposed to adding flags like that; you're right
that they seem fairly safe. Have anything in mind? If not now, let us
know later.
We have long-term goals of allowing multiple compiler-installs such as
fat/universal OSX binaries, installed libraries for multiple C++
compilers (e.g., the wrapper compiler would pick the "right" one
somehow), but those goals are a ways off.
I guess I still don't understand why -- all the reasons you cited
above
are going to be problematic regardless of whether you're using a
wrapper compiler or not. All that mpicc (and friends) do is add the
proper -I, -L, -l, and other flags (like -pthread). That's it. Which
you use to link your application / create your shared library is still
up to you (e.g., mpicc/c++/f77/f90), for example.
Well, unfortunately not. Some of those flags and libraries
linked by an arbitrary (not necessarily your) mpi wrapper
may make very definite assumptions about things like c++ or dynamic
loading.
That's fine when all the code in all the components in the
final executable are built with your compiler wrapper.
Unfortunately people have the habit of using serial libraries
built ahead of time with non-mpi compilers in parallel applications.
They even still do things like use pvm in mpi applications.
Frequently it's much easier to extract CXXFLAGS and propagate them
than it is to convince some third-party configure script
to accept mpicxx as a compiler.
Ok, I can see the "users are silly" argument, and I guess I shouldn't
try to speak for any other wrappers other than mine, but can't any
Autoconf-generated configure script be used thusly:
./configure CXX=mpicxx ...
I have done this myself many times.
I think I'm still somehow missing the crux of your argument (apologies;
it's the end of a long day). Can you give a concrete example where a
wrapper won't work? (see below)
Let me know if the wrappers work for you (ditto for LAM/MPI; the
wrappers in OMPI are basically the same -- but slightly expanded -- as
the wrappers from LAM/MPI). I have only seen one situation (extremely
recently) where a LAM user *couldn't* use the wrapper compilers, but
they wanted to intercept MPI calls in a fairly non-standard way, so we
judged that an acceptable failure for the wrappers (i.e., the user was
satisfied with --showme:foo).
On my list to test. That's why the bootleg source. I'm optimistic
from what i've seen, but busy getting out some papers just now.
No problem-o.
Give it a whirl when you get a chance and let us know if something
breaks. Then let's figure out how to fix it.
Not a bad idea.
I'd also want to make it possible for systems to *not* give that
warning, or perhaps give aliases that mean "don't warn if I'm using
this compiler", or somesuch. You can easily imagine scenarios where
amen.
One other project I know provides
--override-installpath
to suppress warnings about compilers being different
from those the wrapper saw.
Duly noted.
Any other suggestions?
Probably, but only after I get to more extensively test things.
The [e-mail] door is always open.
In the default build I managed, it looks like as part of
your architecture there simply is no obvious option to static-link
the entire application. Did I miss some files/(some goofy ELF feature)
someplace, or is this true?
I can live with it, but some people I know on exotic platforms
are gonna be unhappy. Of course maybe on those platforms we just
use the vendor mpi and forget it.
The default build is to make libmpi be a shared library and build all
the components as dynamic shared objects (think "plugins").
But we currently use Autoconf+Automake+Libtool, so to build everything
static, the standard flags suffice:
./configure --enable-static --disable-shared
This will make libmpi.a, all the components are statically linked into
libmpi.a, etc. There's more esoteric configure flags that allow
building some components as DSOs and others statically linked into
libmpi, but most people want entirely one way or the other, so I won't
provide the [uninteresting] details here.
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
