Re: [OMPI devel] 1.4.4rc2 is up

[Larry Baker]

Jeff,

I ran into some kind of link error, I think, with PGI 10.3 and OpenMPI  
1.4.2 last year.  I am building a new cluster and we have PGI 11.4  
now.  I am consulting my notes and patches from 1.4.2 to inspect 1.4.3  
to see if the problems I had have been fixed.  I found the .m4 files I  
patched in 1.4.2 were identical in 1.4.3, so I fixed them right off  
the bat.  I found the same was true for the detection of inline  
assembly with C++.  Other problems I had with PGI 10.3 have been fixed  
with PGI 11.4, but I patched them anyway so OpenMPI 1.4.3 will still  
compile cleanly on PGI 10.x.  (I haven't sent you all of those for  
1.4.3; I sent them last year for 1.4.2.)  Finally, I patch the shell  
scripts that generate the Fortran 90 interface routines to remove the  
spurious declarations (without implementations, of course) of  
Character and Logical MPI_SIZEOF() generics, convert dummy arrays to  
assumed-shape arrays, and substantially clean them up/shrink them.

I have compiled and tested (make check) my patched OpenMPI 1.4.3 with  
Rocks 5.4 (CentOS 5.5) gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)  
and PGI pgcc 11.4-0 64-bit target on x86-64 Linux -tp nehalem.  I have  
not been so successful yet with Intel icc Version 12.0.3.174 Build  
20110309.  I have yet to try AMD x86 Open64 GNU gcc version 4.2.0  
(Open64 4.2.5 driver) or whatever I get from PathScale when I transfer  
the license from our old cluster to the new one.

After I get through OpenMPI 1.4.3, I should have time to test 1.4.4.   
Will there be another 1.4.4 release candidate?  Do I have to hurry to  
give you my feedback?

Larry Baker
US Geological Survey
650-329-5608
address@hidden

On 19 May 2011, at 6:58 PM, Jeff Squyres wrote:

> With all the outputs from Paul and Sam, I think we'll be good.
>
> ...hmmm.  Wait.  I see that our 1.4.x configure *is* patched to have  
> the extra ".".  Here's the lines from configure in 1.4.3 and 1.4.4rc2:
>
>            # Portland Group C++ compiler
>            case `$CC -V` in
>            *pgCC\ [1-5].* | *pgcpp\ [1-5].*)
>
> It's not in the .m4 file because we patch configure *after* the m4  
> file is used to generate configure (Don't ask -- it's a long,  
> twisted story).
>
> Can you say what the original problem was that eventually led you to  
> this patch?
>
>
>
> On May 18, 2011, at 2:08 PM, Larry Baker wrote:
>
> > Jeff,
> >
> > > Is this guaranteed to work for all versions of the PGI compiler?   
> > > I.e., does "pgCC -V" always return something in the form of (digit) 
> > > +\. ?
> >
> > I don't know, but I think so.  See your Nov 2009 discussion of this  
> > bug and Ralf Wildenhues' libtool.m4 patches at http://www.open-mpi.org/community/lists/users/2009/11/11277.php 
> > .
> >
> > Larry Baker
> > US Geological Survey
> > 650-329-5608
> > address@hidden
> >
> > On 18 May 2011, at 5:50 AM, Jeff Squyres wrote:
> >
> > > (adding address@hidden)
> > >
> > > Is this guaranteed to work for all versions of the PGI compiler?   
> > > I.e., does "pgCC -V" always return something in the form of (digit) 
> > > +\. ?
> > >
> > >
> > > On May 17, 2011, at 8:52 PM, Larry Baker wrote:
> > >
> > > > This bug applies to OpenMPI 1.4.x and 1.5.x.
> > > >
> > > > The libtool.m4 in config and opal/libltdl/m4 do not properly  
> > > > determine the version of the PGI compiler, which then set the  
> > > > wrong compile/link options.  They interpret V11.4 (version no.  
> > > > begins with a 1), for example, as being a V1 to V5 compiler.   
> > > > There is a missing period in the pattern, so that only text like  
> > > > 1.x through 5.x matches.
> > > >
> > > > Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
> > > >
> > > > > address@hidden openmpi-1.4.3]# diff -u config/libtool.m4{.original,}
> > > > > --- config/libtool.m4.original  2010-10-05 15:45:44.000000000 -0700
> > > > > +++ config/libtool.m4   2011-05-17 15:32:31.000000000 -0700
> > > > > @@ -5896,7 +5896,7 @@
> > > > >         pgCC* | pgcpp*)
> > > > >           # Portland Group C++ compiler
> > > > >             case `$CC -V` in
> > > > > -           *pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
> > > > > +           *pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
> > > > >               _LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
> > > > >                 rm -rf $tpldir~
> > > > > 		$CC --prelink_objects --instantiation_dir $tpldir $objs  
> > > > > $libobjs $compile_deplibs~
> > > >
> > > > Larry Baker
> > > > US Geological Survey
> > > > 650-329-5608
> > > > address@hidden
> > > >
> > > > On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
> > > >
> > > > > Fixed the ROMIO attribute problem properly this time -- it's in  
> > > > > the usual place:
> > > > >
> > > > > http://www.open-mpi.org/software/ompi/v1.4/
> > > > >
> > > > > --
> > > > > Jeff Squyres
> > > > > address@hidden
> > > > > For corporate legal information go to:
> > > > > http://www.cisco.com/web/about/doing_business/legal/cri/
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > devel mailing list
> > > > > address@hidden
> > > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > > >
> > > > _______________________________________________
> > > > devel mailing list
> > > > address@hidden
> > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > >
> > >
> > > --
> > > Jeff Squyres
> > > address@hidden
> > > For corporate legal information go to:
> > > http://www.cisco.com/web/about/doing_business/legal/cri/
> > >
> > >
> > > _______________________________________________
> > > devel mailing list
> > > address@hidden
> > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> Jeff Squyres
> address@hidden
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/