> -----Original Message-----
> From: users-boun...@open-mpi.org
> [mailto:users-boun...@open-mpi.org] On Behalf Of Reuti
> Sent: Tuesday, October 21, 2008 11:36 AM
> To: Open MPI Users
> Subject: Re: [OMPI users] OpenMPI runtime-specific
> environment variable?
>
> Hi,
>
> Am 21.10.2008 um 18:52 schrieb Ralph Castain:
>
> > On Oct 21, 2008, at 10:37 AM, Adams, Brian M wrote:
> >
> >> Doug is right that we could use an additional command line flag to
> >> indicate MPI runs, but at this point, we're trying to hide
> that from
> >> the user, such that all they have to do is run the binary vs.
> >> orterun/mpirun the binary and we detect whether it's a serial or
> >> parallel run.
>
> And when you have this information you decide for your user,
> whether to use mpirun (and the correct version to use) or
> just the plain binary?

I might have created some confusion here too.  The goal is to build an 
MPI-enabled binary 'foo' which a user may invoke as

(1) ./foo
-OR-
(2) mpirun -np 4 ./foo

The binary foo then determines at run-time whether it is to run in (1) serial, 
where MPI_Init will never be called; or (2) parallel, calling MPI_Init and so 
on.  This is a historical behavior which we need to preserve, at least for our 
present software release.

> You are making something like "strings the_binary" and grep
> for indications of the compilation type? For the standard
> Open MPI with shared libraries a "ldd the_binary" might
> reveal some information.

Hadn't thought to do that actually, since it addresses a slightly different 
problem than I propose above.  Thanks for the suggestion.  This is another 
possibility if instead of doing this detection directly in our binary, we 
decide to change to a wrapper script approach.

In any case, I appreciate all the discussion -- I believe I have a reasonable 
path forward using a combination of pre-processor defines that the OMPI 
wrappers and headers make with the runtime environment variables Ralph 
suggested (I'll just check for both the <1.3 and >= 1.3 environment cases).

Brian


Reply via email to