MPICH vs. AIX-MPI on frost?

[Robert Latham]

On Fri, Jul 25, 2003 at 09:04:09AM -0700, Tyce Mclarty wrote:
> Well, I learned a lot yesterday about AIX, F90, and configure. Found 
> several things in configure and build procedure that look like they need to 
> be changed. Summary:
> 
> 1. The basic idea in README.frost is right, but have to be very careful 
> about consistently using either mpich or ibm resources. I had to hunt a 
> little to find the ibm mpi libraries to point to with --with-mpi. The final 
> script I ended up with is atached.

> 2. Hit some glitches just using ibm's make. Much better when I used gmake 
> all the time. Need a warning in INSTALL.

What sort of glitches?  we'd like to have our makefile work for both
ibm and linux machines (for starters... 100% portable makefiles might
just be impossible :> )

> 3. In configure script where it checks mpi implementation, it assumes names 
> mpicc and mpif77 _always_. I had to edit this to use ibm names mpcc_r and 
> mpxlf_r. In a rational world you could just set CC & F77 to the right 
> mpi-name and it would work. However, on our systems the earlier checks on 
> cross-compiling almost always fail using those names. We've been fighting 
> this with the hdf5 configure for years. So unless you allow an environment 
> variable for MPICC and MPIF77, I don't know how to handle it.

Yes, guilty as charged.  I'll fix it so that you can specify MPICC and
MPIF77.

> 4. I got really frustrated trying to edit configure.in with no effect for a 
> while til I finally figured out it's not used. WHy not get rid of it?

the configure script is autogenerated from configure.in by the
'autoconf' program.

> 5. The FCALLSCSUB area where its trying to figure Fortran name mangling. I 
> struggled with this for hours trying to get a consistent choice. Finally 
> figured out that the ibm default is no name change which is what happens 
> when it drops through the first test, but not if it passes the first test 
> and fails to find a match. Confusing part was that both give the same 
> warning message. Needs to say what is done, not just what problem is.
> 
> Part of my confusion was that I'm sure the first few tims I ran it, it 
> passed the first test because it created the confdefs.h file. Now it 
> doesn't do that anymore, but I don't know why.
> !! This is the answer to my last problem - why the fortran build fails with 
> NF_INT_IS_C_INT, etc. all undefined. Configure never tried to define them 
> because it FCALLSCSUB is empty.

Maybe emails have crossed paths or perhaps i didn't reply to enough
people:  yesterday evening i suggested adding 'UD_CHECK_FCALLSCSUB' to
configure.in and re-running autoconf would give you a configure that
would at least get the fortran name mangling correct.   We might not
be calling the linker correctly on the SP, but at least we'll be
trying to link objects with the correct symbols.

> 6. In C test programs ibm C compiler complained that there was no break; 
> after the default: statements, or maybe just because they were empty. WHat 
> a pain.

gcc 3.0 and newer flag that as a warning, but not an error.  Is it an
error with the ibm compiler?

> 7. Edited macros.make for FFLAGS = -d. From documentation, this should not 
> be needed, but seemed to make it work when it wasn't.

ok, i'm not sure what the -d flag does, but maybe i should make it a
part of the FFLAGS by default?

> I need to think some more about item 5. Have a telecon now.

Thanks for the detailed report.  we'll try to address these issues and
make building on the SPs go a lot smoother as soon as we can.

==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA                B29D F333 664A 4280 315B