MPICH vs. AIX-MPI on frost?

[Tyce Mclarty]

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.

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.

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?

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.

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.

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

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

Tyce

At 07:55 PM 7/23/2003 -0500, Rob Ross wrote:
>On Wed, 23 Jul 2003, Tyce Mclarty wrote:
>
> > It looked to me like there was a problem with mixing IBM and mpich scripts
> > and/or libraries with the approach in the README.frost and in the INSTALL
> > files with the distribution. I have not gotten a pure mpich configure to
> > work, but did work out a pure IBM one.
> >
> > What you found may be a problem, but I think we have something more basic.
> > When I get configure to run, there is a warning about an "unrecognized
> > fortran name mapping". So it sounds like the IBM compilers are doing
> > something unexpected with fortran names. Not too surprising.
> >
> > This would explain why C works fine, but not fortran. I can do some 
> digging
> > through the AIX documentation or catch the guy over here who will know
> > right away in the AM.
>
>There's some badness in how we figure out what prefixes to put on fortran
>symbols; we're going to look into this too.
>
>Sorry about all the rough edges...
>
>Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure
Type: application/octet-stream
Size: 116213 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20030725/31ad216b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ibm-config
Type: application/octet-stream
Size: 843 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20030725/31ad216b/attachment-0001.obj>