[bug#27905] changes for openmpi

[Dave Love <fx@gnu.org>]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

>> * mpi.scm (hwloc)[outputs]: Replace lib with nogui.
>> (hwloc)[arguments]: Change configure --prefix; use "nogui" output,
>> not "lib"; populate "all" output.
>> (openmpi)[inputs]: Use hwloc-nogui.
>
> The downside of this is that the “nogui” output is less discoverable
> (and it’s another user-visible breakage.)

I don't think that's a problem, as people who want to avoid the GUI
stuff will look for an alternative.

> Also, it shouldn’t make any difference to the closure size of openmpi
> anyway, no?

No, but I think you should be able to run the hwloc programs on compute
nodes without requiring X support, and you sometimes need to run openmpi
programs specifically with openmpi (for memory affinity, for instance).

> > +         (add-after 'install 'install-openmpi
> > +           (lambda* (#:key outputs #:allow-other-keys)
> > +             (let ((dest (format #f "~a/lib/valgrind"
> > +                                 (assoc-ref outputs "openmpi"))))
> > +               (mkdir-p dest)
> > +               (zero?
> > +                (system (format #f "mv ~a/lib/valgrind/libmpiwrap* ~a"
> > +                                (assoc-ref outputs "out") dest)))))))))
> 
> Why move it to a separate output?  After all, we can keep it in “out”
> since all it costs is the size of libmpiwrap.so, right?

That would still pull in valgrind, which drags in a lot else (gdb, perl,
python...).  The support isn't commonly used as far as I can tell, and
isn't configured by default -- I forgot about the performance hit
<https://www.open-mpi.org/faq/?category=debugging#memchecker_overhead>.

> Also, I assume that this is functionally equivalent to Open MPI’s
> built-in Valgrind support, is it?

I think so, basically, but I can ask the question.  (Actually it's
occurred to me that the wrapper uses the profiling interface, so it
won't work together with profiling tools without pnmpi multiplexing, but
you're unlikely to want to stack one with memory debugging.)  Anyhow, I
vote against a performance hit generally.  Also, versions of the wrapper
library could be provided for other MPIs when they're packaged.  If
memchecker really needs to be built-in, I think it should be packaged
separately openmpi, as for thread-multiple support.

I'll report any reply I get about the built-in support.