[OMPI devel] Issues with 1.2 and intel/portland compilers
I've been trying to build the openmpi 1.2 branch with the Intel and Portland Fortran compilers and was having trouble using their -i-static/-Bstatic_pgi options. First off, it seems the only way to get these options to appear in the necessary link lines is to add them to the compiler variable itself, e.g.: FC="ifort -i-static" However, this causes problems with some configure checks in setting the OMPI_F90_ABSOLUTE and similar variables, because "which" complains about the extra arguments. I ended up making the following change: --- openmpi-1.2-20061010/config/ompi_setup_f77.m4.which 2006-10-12 09:29:04.534724449 -0600 +++ openmpi-1.2-20061010/config/ompi_setup_f77.m4 2006-10-12 09:29:36.840254496 -0600 @@ -59,7 +59,7 @@ else OMPI_F77="$F77" BASEF77="`basename $OMPI_F77`" -OMPI_F77_ABSOLUTE="`which $F77`" +OMPI_F77_ABSOLUTE="`which $BASEF77`" if test "$OMPI_WANT_F77_BINDINGS" = "0" ; then AC_MSG_WARN([*** Fortran 77 bindings disabled by user]) --- openmpi-1.2-20061010/config/ompi_setup_f90.m4.which 2006-10-12 09:29:11.059841268 -0600 +++ openmpi-1.2-20061010/config/ompi_setup_f90.m4 2006-10-12 09:29:49.770468395 -0600 @@ -88,7 +88,7 @@ OMPI_WANT_F90_BINDINGS=1 OMPI_F90="$FC" BASEF90="`basename $FC`" -OMPI_F90_ABSOLUTE="`which $FC`" +OMPI_F90_ABSOLUTE="`which $BASEF90`" fi fi # make sure the compiler actually works, if not cross-compiling which works for a single extra argument because basename doesn't complain. However, basename does complain if you give it more arguments. Something more general might be: BASEF90=`echo $FC | sed 's/ .*//'` BASEF90="`basename $BASEF90`" OMPI_F90_ABSOLUTE="`which $BASEF90`" I'm not sure what the most cross platform way to return only the first argument is. Of course, if there was a way to get these passed to the appropriate link stages, we could avoid this. But it looks like libtool strips the -i-static argument and doesn't pass it on to the link command, not sure about the -Bstatic_pgi argument. -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: [OMPI devel] Issues with 1.2 and intel/portland compilers
Hello Orion, * Orion Poplawski wrote on Thu, Oct 12, 2006 at 06:57:04PM CEST: > I've been trying to build the openmpi 1.2 branch with the Intel and > Portland Fortran compilers and was having trouble using their > -i-static/-Bstatic_pgi options. Your report touches several issues: > I'm not sure what the most cross platform way to return only the first > argument is. ompi_setup_f77.m4 should allow for more than one word in $F77. Autoconf typically uses something like this to extract the first word: # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 so OpenMPI could use that, too (with variable names changed, of course, so they don't interfere with Autoconf's), > Of course, if there was a way to get these passed to the appropriate > link stages, we could avoid this. But it looks like libtool strips the > -i-static argument and doesn't pass it on to the link command, not sure > about the -Bstatic_pgi argument. Yes, this is a problem. On the libtool command lines, you can use -Wc,-i-static to get -i-static passed to the compiler driver; and -Wl,-i-static to get it passed to the linker directly (but that would be wrong in this case). Unfortunately, you may not in general be able to stuff this in LDFLAGS at configure time (I haven't tried, it may just happen to work), so one different way would be to stick it in at make time only: make LDFLAGS=... But then, configuring with > FC="ifort -i-static" is a much better option: it tests the right setting at configure time. Note there may still be issues: libtool should actually be able to understand what -i-static really means (and for example not worry about those libraries that are linked statically). But the FC setting should get you going. Hope that helps. Cheers, Ralf
[OMPI devel] configure changes tonight
Hi all - There will be three configure changes committed to the trunk tonight: - Some cleanups resulting from the update to the wrapper compilers for 32/64 bit support - A new configure option to deal with some fixes for the MPI::SEEK_SET (and friends) issue - Some cleanups in the pthreads configure tests The only real affect for everyone should be that you'll have to re-autogen.sh. And that the 32/64 include and libdir flags will no longer be available. I will be updating the wiki shortly w.r.t. how to build a multilib wrapper compiler shortly. Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/
[OMPI devel] Something broken using Persistent Requests
I am getting errors using persistent communications (OMPI 1.1.1). I am trying to implement (in Python) example 2.32 from page 107 of MPI- The Complete Reference (V1, 2nd. edition). I think the problem is not in my wrappers (my script works fine with MPICH2). Below the two issues: 1 - MPI_Startall fails (returning a negative error code, -105, which in fact it seems to be out of range [MPI_SUCCESS...MPI_LASTCODE]). However, doing 'for r in reqlist: r.Start()' works. 2 - And then, calling MPI_Waitall (or even iterating over request array and calling MPI_Wait), the request seems to be deallocated (I get MPI_REQUEST_NULL upon return), so I cannot start them again. I understand this is wrong, the request handles should be marked as inactive, but not for deallocation. Please, ignore me if this was reported. I am really busy and I have not found the time to navigate the OMPI sources to get in touch with its internal, so I am always reporting problems, and never patches. Sorry! -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
