This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
> 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.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"
> 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.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="`echo $with_ident_string | sed -e
> +with_ident_string="`echo $with_ident_string | sed -e
> AC_DEFINE_UNQUOTED([OPAL_IDENT_STRING], ["$with_ident_string"],
> [ident string for Open MPI])
> 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.CTR_at_[hidden]>
> 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:baker_at_[hidden]]
> 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
> 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
> devel mailing list
For corporate legal information go to: