Re: [OMPI users] mpi.h macro naming

2008-02-24 Thread Jeff Squyres
Actually, I take my comments back.  Brian's initial patches did not  
compiled for me; I had to make some more changes to make it work for  
me (see attached patch):


1. fixed a HAVE_LONG_LONG to be OMPI_HAVE_LONG_LONG

2. fixed a STDC_HEADERS to be OMPI_STDC_HEADERS

3. the AC_DEFINE's for the new OMPI_* macros in mpi.h were at the very  
beginning of configure.ac, before the various $ac_cv_ shell  
variables had any values (hence, the resulting #defines were empty).   
I moved them to the end of configure.ac.


The only one that concerns me is #3 -- Brian: was there a reason you  
put those AC_DEFINE's at the top of configure.ac?


Given that the previous patch must have somehow compiled for Brian,  
I'd like to get a review before this is committed to the trunk.  I  
tested on x86_64 RHEL4U4 and OS X Leopard and my amended patch seems  
to work.  Can someone else verify that the attached patch works for  
them before I commit?




On Feb 23, 2008, at 1:20 PM, Jeff Squyres wrote:


I merged your two patches and will commit once I come within range of
being online.  I'll also file a CMR for 1.2.6 in case that ever
happens (had to resolve a trivial patch reject for the 1.2 branch).

Thanks!


On Feb 22, 2008, at 9:40 AM, Brian W. Barrett wrote:


A second attempt, this time with less suck :).

Brian

On Fri, 22 Feb 2008, Brian W. Barrett wrote:


Oops..  forgot to test the C++ bindings, which of course broke.
Let me
try again and I'll send a better patch.

brian

On Fri, 22 Feb 2008, Brian W. Barrett wrote:


On Thu, 21 Feb 2008, Jeff Squyres wrote:


While I agree that having AC actually define them to a value is a
Good
Thing (better than just defining it to be empty), I do see the
pickle
that it has put us in.  :-\  I don't see an obvious solution.


I do :).  Try the attached patch.  It sneaks in at the last minute
and
defines (for example) both SIZEOF_BOOL and OMPI_SIZEOF_BOOL.
mpi.h only has
the define for OMPI_SIZEOF_BOOL.  opal_config.h has both, but a
note saying
not to use the OMPI_ version.  Seems to work.

Brian


___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

< 
ompi_mpi_h_no_ac.diff>___

users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users



--
Jeff Squyres
Cisco Systems

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users



--
Jeff Squyres
Cisco Systems


mpi.h.in.patch
Description: Binary data




[OMPI users] Problems with f90 implementation under Leopard

2008-02-24 Thread Gregory J. Orris

Hey,

Been trying to activate mpif90 on a set of machines running Leopard  
for some colleagues and have gotten stuck.

Compiles fine, but will not run any examples and returns

mymachine me% /usr/local/mpiexec -np 2 ./ring_f90
[mymachine.local:23974] *** An error occurred in MPI_Comm_rank
[mymachine.local:23974] *** on communicator MPI_COMM_WORLD
[mymachine.local:23974] *** MPI_ERR_COMM: invalid communicator
[mymachine.local:23974] *** MPI_ERRORS_ARE_FATAL (goodbye)
[mymachine.local:23975] *** An error occurred in MPI_Comm_rank
[mymachine.local:23975] *** on communicator MPI_COMM_WORLD
[mymachine.local:23975] *** MPI_ERR_COMM: invalid communicator
[mymachine.local:23975] *** MPI_ERRORS_ARE_FATAL (goodbye)

Seems tied up in how gfortran implements parameters. If MPI_COMM_WORLD  
is changed in the example code to 0 (its parameter value) all is fine.  
In the recesses of my mind I seem to remember reading ones that  
gfortran used for f90 treats parameters differently than integers.   
Anyone else seen this?


BTW mpif77 works without problems.

Regards,
Greg