On Thu, Jun 16, 2005 at 06:33:51PM -0400, Jeff Squyres wrote: > On Jun 16, 2005, at 2:58 PM, Ben Allan wrote: > > The only reason to have something like ompiConf.sh is to use the > frameworks that already exist (like the gnome-conf thingy). I was only > tossing that out as an example -- I didn't know if you were looking to > use a standardized tool or didn't really care where the info came from > as long as there was a defined interface to it. > > It sounds like the latter.
I'm sure any standardized tool i assume won't be there, so yes, the latter. > > As usual, mpicc --help doesn't show showme as an option. > > 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. > 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. > > portability to horrors like AIX, etc, all wrappers are > > taken with a grain of salt. > > 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. > I remember that MPI wrapper compilers in the mid- and late-90's were > pretty crappy. But I think they're all gotten pretty reasonable of > late (I could be wrong here, though...?). I pray you're right, but am skeptical. > 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. > Are you saying that your configure re-orders the flags that you're > getting back from MPI installations? Well, I very much prefer to avoid doing that kind of thing, but S*** happens. usually I try to convince people to go through CXXFLAGS in the env or something rather than rehack multiple configure scripts. > Ah, ok. That's easy enough to do (too late for beta, I'll commit this > on the trunk tonight -- we try not to make configure.ac changes during > the work day; it keeps peer developer frustration down ;-) ). > > Slight rename, though: > > ----- > shell$ ./ompi_info --parsable -c | grep compiler: | egrep > ':command:|:absolute:' > compiler:c:command:gcc > compiler:c:absolute:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130/gcc > compiler:cxx:command:g++ > compiler:cxx:absolute:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130/g++ > compiler:f77:command:g77 > compiler:f77:absolute:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130/g77 > compiler:f90:command:none > compiler:f90:absolute:none > ----- > > That's two minor changes: > > 1. Making the second field stay the name for easy grouped grepping > (e.g., grepping on "compiler:c:" gets all info about the C compiler); > make the 3rd field be different. > > 2. Change it from "which" to "absolute", because "which" reflects a > command that not everyone will necessarily be familiar with. Indeed, > we're really presenting the absolute filename of the compiler as it was > located in the $PATH. > > Acceptable? sure. well-defined is the best i can hope for absent an mpi standard. > 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. > Any other suggestions? Probably, but only after I get to more extensively test things. 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. thanks, Ben
