Wait -- I'm a total bozo... (attribute it to a lack of caffeine this
morning!)
There's a far simpler solution -- just change the underlying compiler
that LAM is using in the wrapper compiler. For example (this assumes a
Bourne-like shell):
shell$ export LAMHCP="purify cc"
shell$ mpicc myprogram.c -o myprogram
This will tell LAM to use "purify cc" as your underlying compiler, and
should do all the Right Things (i.e., the "purify" command will never
see the command "mpicc"; it will only see "cc" [or whatever underlying
compiler you are using]). Ensure that you have configured and compiled
LAM with --with-purify to avoid a bunch of false positive results.
Sorry for the confusion; hope this helps.
On Jul 20, 2004, at 8:05 AM, Jeff Squyres wrote:
> Well, that's unfortunate that purify doesn't understand "mpicc".
>
> Note on rationale here: we've always referred to the "memory clean"
> model in LAM as "purify clean" because Purify is just a well-known
> tool; we've never actually owned or used Purify (and therefore we
> didn't know that Purify would complain about mpicc). Instead, we've
> mainly used the tools bcheck (on Solaris) and valgrind (on Linux).
> Sorry for the confusion... :-\ I'll update the FAQ.
>
> I think you have 3 main options:
>
> 1. Since you appear to be using Solaris, don't use purify, and instead
> use the Solaris native "bcheck" command. This means that you have to
> use the native Solaris compilers (cc, CC, f77) when you configure LAM.
> Then you can have a script that runs "bcheck -all your_executable",
> as suggested on the FAQ.
>
> 2. It looks like "purify" is a script and is keying off the name of
> the compiler "mpicc". You could hack the
> /opt/rational/releases/purify.sol.2002a.06.00/purify.sh script to
> treat "mpicc" exactly the same as whatever underlying compiler you are
> using (e.g., cc). Or you could copy that script to somewhere you can
> modify it (e.g., the cwd), modify it, and run it from there. This may
> or may not be an attractive solution for you.
>
> 3. Remember that "mpicc" is only a wrapper compiler -- it only adds /
> removes some command line flags and then invokes the underlying
> compiler. Use the "-showme" flag to mpicc to get the additional flags
> that you need. Note that "-showme" is context-sensitive, however --
> different flags will be shown for compiling than linking. For
> example, the following will show two different results:
>
> mpicc -c foo.c -showme
> mpicc foo.o -o foo -showme
>
> Then you can change your Makefile to use the actual underlying
> compiler and whatever relevant compiler / linker flags LAM needs.
>
> Note that we typically *strongly* discourage people from not using
> mpicc (and friends) because we are likely to change the flags that
> mpicc (etc.) use without warning in each LAM release. Hence, putting
> a fixed set of flags in your Makefile may work for one version of LAM,
> but not work for another.
>
> However, this unfortunately seems to be a legitimate use of needing to
> get these flags and avoiding the use of the wrapper compiler. So
> here's your undocumented tip of the day (we were hoping never to have
> to reveal this feature)...
>
> mpicc -showme:compile
> mpicc -showme:link
>
> will show you the CFLAGS and LDFLAGS/LIBS, respectively. These flags
> were introduced in LAM 7.0. I don't remember the syntax offhand, but
> I believe that gmake allows you to run arbitrary commands in a
> Makefile and assign the results to a macro. You can therefore run
> these commands and add the results to CFLAGS and LIBS, and then use
> the underlying compiler (which the purify script understands).
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
