Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-06-16 19:44:48


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/