Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: [OMPI devel] ROMIO build broken in 1.5.5rc1 [SOLVED]
From: Paul H. Hargrove (PHHargrove_at_[hidden])
Date: 2012-01-31 18:17:50

On 1/31/2012 1:53 PM, Paul H. Hargrove wrote:
> I can supply details if anybody want to work on this ahead of
> 1.5.5rc2, but the short report is:
> gmake[3]: Entering directory
> `/home/phargrov/OMPI/openmpi-1.5.5rc1-openbsd5-amd64/BLD/ompi/mca/io/romio/romio'
> Making all in include
> make: don't know how to make w. Stop in
> /home/phargrov/OMPI/openmpi-1.5.5rc1-openbsd5-amd64/BLD/ompi/mca/io/romio/romio/include.

I took a quick look and discovered that all the generated Makefile's
under ompi/mca/io/romio/romio contain explicit MAKE=make (twice per
Makefile, actually). This leads to the "make: don't know how to make w.
Stop" message above when GNU make (which I was using due to the
asm-generation issue) recursively invokes the romio build which then
switches over to Berkeley Make. I am guessing that gmake has left some
droppings in $(MAKE_FLAGS) or similar which is causing Berkeley Make to
think it should build the target "w".

This could be classified as "pilot error" since I didn't inform ROMIO at
configure time that I was using gmake.

The solutions include:

1) If one want to build with a non-default make, then add "MAKE=gmake"
(or similar) to the configure command line so ROMIO encodes the proper
value in the generated Makefile's. This should be documented in the
README with the other configure settings.

2) Building w/ Berkeley Make (once the GNU Make dependencies have been
For users who have not aliased or otherwise displaced make in favor of
gmake, that should be the default anyway.

3) Build with "gmake MAKE=gmake" since command-line values override the
one in the Makefiles.

I noticed that ompi/mca/io/romio/romio/ already contains
many attempts to prevent setting MAKE (all marked with "Open MPI:"
comments). So, it appears you have already tried (but apparently
failed) to address the one-should-not-set-MAKE-in-Makefile issue.

In the end, documenting #1 is all that is really required and is
probably much easier than fixing ROMIO.


Paul H. Hargrove                          PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900