Tom / Larry -- Thanks for looking into this.
1. I just replied on https://svn.open-mpi.org/trac/ompi/ticket/2913 about the sed issue; let's iterate there to find the Right solution. 2. Larry: I'll look at the other issues in your patch more closely after the Thanksgiving break (I'm supposedly on vacation today; I'm going to be in trouble if I don't stop working soon!). On Nov 15, 2011, at 8:17 PM, Thomas Rothrock CTR SMDC SimCtr/GaN Corporation wrote: > Thank you for the reply and attachments. I searched the archive before > sending my own email and did find a couple of the previous messages, but > believe mine is a different situation. The macro expansion is working (I'm > using PGI 11.10) but the macro is set to "" instead of "1.7a1? (no > svnversion) MM-DD-YYYY" by an error in the configure script generation. > Installing subversion is a cheap workaround that makes the svnversion > command available and the macro gets set to "1.7a1r25476M" or whatever repo > version you are at. > > I did not mention it before but this happens when I try to build the trunk > or the 1.5 development branch. The 1.4 branch's configure code doesn't even > bother to test for svnversion failing and just ends up setting OMPI_VERSION > to "1.4.4rc5r" > > The problem is with configure's with_ident_string assignment: > > with_ident_string="`echo $with_ident_string | sed -e > 's/%VERSION%/'$OMPI_VERSION/`" > > OMPI_VERSION is set to "1.7a1? (no svnversion) MM-DD-YYYY" but the spaces in > OMPI_VERSION break the expression because sed sees the rest of the version > string as extra arguments instead of part of the -e script. It doesn't show > up in config.log, but the configure output to the terminal at this point is: > > checking if want ident string... sed: -e expression #1, char 18: > unterminated `s' command > > The config.status shows: > > D["OPAL_IDENT_STRING"]=" \"\"" > > If I patch config/opal_get_version.m4 to remove the spaces: > > > > diff -Naurd openmpi-trunk.a/config/opal_get_version.m4 > openmpi-trunk.b/config/opal_get_version.m4 > --- openmpi-trunk.a/config/opal_get_version.m4 2011-09-21 > 23:17:36.000000000 -0500 > +++ openmpi-trunk.b/config/opal_get_version.m4 2011-11-15 > 17:36:09.000000000 -0600 > @@ -81,7 +81,7 @@ > if test $? != 0; then > # The following is too long for Fortran > # $2_REPO_REV="unknown svn version (svnversion not > found); $d" > - $2_REPO_REV="? (no svnversion); $d" > + $2_REPO_REV="?(nosvnversion);$d" > fi > elif test -d "$srcdir/.hg" ; then > # Check to see if we can find the hg command > > > > it verifies that the spaces were the problem. OMPI_VERSION gets set to > "1.7a1?(nosvnversion);11-15-2011", configure runs without an sed error, and > config.status shows: > > D["OPAL_IDENT_STRING"]=" \"1.7a1?(nosvnversion);11-15-2011\"" > > and opal/runtime/opal_init.c compiles without triggering the misleading PGI > error, but doesn't look quite as pretty. Perhaps a better solution is to > modify the with_ident_string assignment to work correclty with spaces in > OMPI_VERSION intact: > > > > diff -Naurd openmpi-trunk.a/opal/config/opal_configure_options.m4 > openmpi-trunk.b/opal/config/opal_configure_options.m4 > --- openmpi-trunk.a/opal/config/opal_configure_options.m4 2011-11-15 > 17:55:36.000000000 -0600 > +++ openmpi-trunk.b/opal/config/opal_configure_options.m4 2011-11-15 > 18:29:43.000000000 -0600 > @@ -489,7 +489,7 @@ > if test "$with_ident_string" = "" -o "$with_ident_string" = "no"; then > with_ident_string="%VERSION%" > fi > -with_ident_string="`echo $with_ident_string | sed -e > 's/%VERSION%/'$OMPI_VERSION/`" > +with_ident_string="`echo $with_ident_string | sed -e > 's/%VERSION%/'"$OMPI_VERSION"'/'`" > AC_DEFINE_UNQUOTED([OPAL_IDENT_STRING], ["$with_ident_string"], > [ident string for Open MPI]) > AC_MSG_RESULT([$with_ident_string]) > > > In this case the resulting config.status has: > > D["OPAL_IDENT_STRING"]=" \"1.7a1? (no svnversion); 11-15-2011\"" > > and the compile works. I have attached the second patch for both trunk and > 1.5 as it is probably the better solution (don't assume OMPI_VERSION has no > spaces) and I have not found other instances of spaces in the version string > breaking anything. As for OpenMPI 1.4's development branch, I'll leave the > choice to patch or leave as-is for someone else to discuss. > > FYI, PGI has assigned my support request TPR #18274. I'm curious what they > will come back with. > > ----------------------------------------------------------- > Tom Rothrock <thomas.w.rothrock....@us.army.mil> > US Army Space & Missile Defense Command Simulation Center > 256-955-3382 (DSN 645) FAX 256-955-1231 > <http://www.sc.army.mil> Main SimCtr Phone: 256-955-3750 > ----------------------------------------------------------- > This email capability is supported by Department of Defense > systems and is subject to monitoring. Please refrain from > using this address for non-Government purposes. > ----------------------------------------------------------- > > -----Original Message----- > From: Larry Baker [mailto:ba...@usgs.gov] > Sent: Tuesday, November 15, 2011 4:08 PM > To: Thomas Rothrock CTR SMDC SimCtr/GaN Corporation > Cc: Open MPI Developers; Eugene Loh > Subject: Re: [OMPI devel] PGI error invoked when svnversion is unavailable > > Tom, > > This is because the code in OpenMPI presumes macros will be expanded in > pragmas, but that is not required by the C standard. (See my e-mails below > from last year with PGI, TPR 17186.) I fixed OpenMPI 1.4.3 configure in the > attached patch. My patch also disables inline assembly for PGI C++, the > same as for PGI C. (Something similar may also have to be done to solve > Eugene's asm statement warnings on Solaris 11.) It also fixes detection of > support for marshaling Fortran REAL16 and COMPLEX32 data types. > > Larry Baker > US Geological Survey > 650-329-5608 > ba...@usgs.gov > <openmpi-1.5-ident_string.patch><openmpi-trunk-ident_string.patch>_______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
