Re: [OMPI devel] trunk borked -- my fault
Yep -- we discussed this after I committed that fix, and I read up on
the AC docs to see why it worked. I now grok, and have a pending fix
queued up for tonight (just so we don't commit autogen-worthy changes)
that fixes exactly what you're talking about. My patch is almost
exactly the same as yours. :-)
I was literally just about to attach a new patch for v1.3 with *all*
of these fixes on to
https://svn.open-mpi.org/trac/ompi/ticket/1993 (Brian noted exactly
the same issues you did :-) ).
You have taught us well, Obi Wan...
On Aug 11, 2009, at 3:31 PM, Ralf Wildenhues wrote:
Hello,
* Jeff Squyres wrote on Tue, Aug 04, 2009 at 11:38:29PM CEST:
> https://svn.open-mpi.org/trac/ompi/changeset/21759 seems to make us
> play well with AC 2.64. To be honest, I'm not sure why this change
> works, but it does.
First off, the warnings 2.64 spit out were about real issues (that
could
have caused unwanted logic with older Autoconf versions, too, but with
2.64 there are a few more cases with consequences). The fix in 21759
avoids the warnings but likely doesn't do what you would like it to
do.
For example, this code in ompi_setup_f77.m4:
AC_DEFUN([OMPI_PROG_F77],[
AC_PROG_F77([gfortran g77 f77 xlf frt ifort pgf77 fort77 fl32
af77])
])
AC_DEFUN([OMPI_SETUP_F77],[
#
ompi_fflags_save="$FFLAGS"
# Strangeness in AC2.64 forces us to require a macro that calls
# PROG_FC instead of calling it directly. Weird.
AC_REQUIRE([OMPI_PROG_F77])
FFLAGS="$ompi_fflags_save"
will cause the contents of the OMPI_PROG_F77 macro to be expanded
completely before the expansion of the OMPI_SETUP_F77 macro.
That means, the lines
ompi_fflags_save="$FFLAGS"
FFLAGS="$ompi_fflags_save"
will not bracket the AC_PROG_F77 call, as they should. What you
should
do is move these lines to the required macro as well.
The patch below ought to fix up these issues, as well as the scope
push
macro for C++. For clarity, you could also put that in another,
separate macro, and AC_REQUIRE that.
Hope that helps.
Cheers,
Ralf
2009-08-11 Ralf Wildenhues
* config/ompi_setup_f90.m4 (OMPI_PROG_FC, OMPI_SETUP_F90):
Move FCFLAGS save/restore wrap in OMPI_PROG_FC.
* config/ompi_setup_f77.m4 (OMPI_PROG_F77, OMPI_SETUP_F77):
Likewise for FFLAGS.
* config/ompi_setup_cxx.m4 (OMPI_SETUP_CXX)
(_OMPI_SETUP_CXX_COMPILER_HELPER, _OMPI_SETUP_CXX_COMPILER):
Fold OMPI_VAR_SCOPE_PUSH and AC_PROG_CXX{,CPP} calls into a
new helper macro and require that, to fix semantics with respect
to AC_REQUIRE.
Index: config/ompi_setup_f90.m4
===
--- config/ompi_setup_f90.m4(revision 21794)
+++ config/ompi_setup_f90.m4(working copy)
@@ -42,7 +42,9 @@
# This macro is necessary because PROG_FC is REQUIREd by multiple
# places in SETUP_F90.
AC_DEFUN([OMPI_PROG_FC],[
+ompi_fcflags_save="$FCFLAGS"
AC_PROG_FC([gfortran f95 fort xlf95 ifort ifc efc pgf95 lf95
f90 xlf90 pgf90 epcf90])
+FCFLAGS="$ompi_fcflags_save"
])dnl
AC_DEFUN([OMPI_SETUP_F90],[
@@ -86,11 +88,9 @@
# list of 95 and 90 compilers and use it here.
#
-ompi_fcflags_save="$FCFLAGS"
# Strangeness in AC2.64 forces us to require a macro that calls
# PROG_FC instead of calling it directly. Weird.
AC_REQUIRE([OMPI_PROG_FC])
-FCFLAGS="$ompi_fcflags_save"
if test -z "$FC"; then
AC_MSG_WARN([*** Fortran 90/95 bindings disabled (could not
find compiler)])
OMPI_WANT_F90_BINDINGS=0
Index: config/ompi_setup_cxx.m4
===
--- config/ompi_setup_cxx.m4(revision 21794)
+++ config/ompi_setup_cxx.m4(working copy)
@@ -47,11 +47,20 @@
_OMPI_CXX_CHECK_2D_CONST_CAST
])
+# _OMPI_SETUP_CXX_COMPILER_HELPER
+# ---
+AC_DEFUN([_OMPI_SETUP_CXX_COMPILER_HELPER], [
+OMPI_VAR_SCOPE_PUSH(ompi_cxx_compiler_works)
+ompi_cxxflags_save="$CXXFLAGS"
+AC_PROG_CXX
+AC_PROG_CXXCPP
+CXXFLAGS="$ompi_cxxflags_save"
+])
+
# _OMPI_SETUP_CXX_COMPILER()
# --
# Setup the CXX compiler
AC_DEFUN([_OMPI_SETUP_CXX_COMPILER],[
-OMPI_VAR_SCOPE_PUSH(ompi_cxx_compiler_works)
# There's a few cases here:
#
@@ -66,11 +75,8 @@
# both found a c++ compiler and want the C++ bindings (i.e.,
either
# case #1 or #3)
-ompi_cxxflags_save="$CXXFLAGS"
-AC_REQUIRE([AC_PROG_CXX])
-AC_REQUIRE([AC_PROG_CXXCPP])
+AC_REQUIRE([_OMPI_SETUP_CXX_COMPILER_HELPER])
BASECXX="`basename $CXX`"
-CXXFLAGS="$ompi_cxxflags_save"
AS_IF([test "x$CXX" = "x"], [CXX=none])
set dummy $CXX
Index: config/ompi_setup_f77.m4
===
--- config/ompi_setup_f77.m4(revision 21794)
+++ config/ompi_setup_f77.m4(working copy)
@@ -41,7 +41,9 @@
# This macro is necessary because PROG_FC is REQUIREd by multiple
# places in SETUP_F90.
AC
Re: [OMPI devel] trunk borked -- my fault
Hello,
* Jeff Squyres wrote on Tue, Aug 04, 2009 at 11:38:29PM CEST:
> https://svn.open-mpi.org/trac/ompi/changeset/21759 seems to make us
> play well with AC 2.64. To be honest, I'm not sure why this change
> works, but it does.
First off, the warnings 2.64 spit out were about real issues (that could
have caused unwanted logic with older Autoconf versions, too, but with
2.64 there are a few more cases with consequences). The fix in 21759
avoids the warnings but likely doesn't do what you would like it to do.
For example, this code in ompi_setup_f77.m4:
AC_DEFUN([OMPI_PROG_F77],[
AC_PROG_F77([gfortran g77 f77 xlf frt ifort pgf77 fort77 fl32 af77])
])
AC_DEFUN([OMPI_SETUP_F77],[
#
ompi_fflags_save="$FFLAGS"
# Strangeness in AC2.64 forces us to require a macro that calls
# PROG_FC instead of calling it directly. Weird.
AC_REQUIRE([OMPI_PROG_F77])
FFLAGS="$ompi_fflags_save"
will cause the contents of the OMPI_PROG_F77 macro to be expanded
completely before the expansion of the OMPI_SETUP_F77 macro.
That means, the lines
ompi_fflags_save="$FFLAGS"
FFLAGS="$ompi_fflags_save"
will not bracket the AC_PROG_F77 call, as they should. What you should
do is move these lines to the required macro as well.
The patch below ought to fix up these issues, as well as the scope push
macro for C++. For clarity, you could also put that in another,
separate macro, and AC_REQUIRE that.
Hope that helps.
Cheers,
Ralf
2009-08-11 Ralf Wildenhues
* config/ompi_setup_f90.m4 (OMPI_PROG_FC, OMPI_SETUP_F90):
Move FCFLAGS save/restore wrap in OMPI_PROG_FC.
* config/ompi_setup_f77.m4 (OMPI_PROG_F77, OMPI_SETUP_F77):
Likewise for FFLAGS.
* config/ompi_setup_cxx.m4 (OMPI_SETUP_CXX)
(_OMPI_SETUP_CXX_COMPILER_HELPER, _OMPI_SETUP_CXX_COMPILER):
Fold OMPI_VAR_SCOPE_PUSH and AC_PROG_CXX{,CPP} calls into a
new helper macro and require that, to fix semantics with respect
to AC_REQUIRE.
Index: config/ompi_setup_f90.m4
===
--- config/ompi_setup_f90.m4(revision 21794)
+++ config/ompi_setup_f90.m4(working copy)
@@ -42,7 +42,9 @@
# This macro is necessary because PROG_FC is REQUIREd by multiple
# places in SETUP_F90.
AC_DEFUN([OMPI_PROG_FC],[
+ompi_fcflags_save="$FCFLAGS"
AC_PROG_FC([gfortran f95 fort xlf95 ifort ifc efc pgf95 lf95 f90 xlf90
pgf90 epcf90])
+FCFLAGS="$ompi_fcflags_save"
])dnl
AC_DEFUN([OMPI_SETUP_F90],[
@@ -86,11 +88,9 @@
# list of 95 and 90 compilers and use it here.
#
-ompi_fcflags_save="$FCFLAGS"
# Strangeness in AC2.64 forces us to require a macro that calls
# PROG_FC instead of calling it directly. Weird.
AC_REQUIRE([OMPI_PROG_FC])
-FCFLAGS="$ompi_fcflags_save"
if test -z "$FC"; then
AC_MSG_WARN([*** Fortran 90/95 bindings disabled (could not find
compiler)])
OMPI_WANT_F90_BINDINGS=0
Index: config/ompi_setup_cxx.m4
===
--- config/ompi_setup_cxx.m4(revision 21794)
+++ config/ompi_setup_cxx.m4(working copy)
@@ -47,11 +47,20 @@
_OMPI_CXX_CHECK_2D_CONST_CAST
])
+# _OMPI_SETUP_CXX_COMPILER_HELPER
+# ---
+AC_DEFUN([_OMPI_SETUP_CXX_COMPILER_HELPER], [
+OMPI_VAR_SCOPE_PUSH(ompi_cxx_compiler_works)
+ompi_cxxflags_save="$CXXFLAGS"
+AC_PROG_CXX
+AC_PROG_CXXCPP
+CXXFLAGS="$ompi_cxxflags_save"
+])
+
# _OMPI_SETUP_CXX_COMPILER()
# --
# Setup the CXX compiler
AC_DEFUN([_OMPI_SETUP_CXX_COMPILER],[
-OMPI_VAR_SCOPE_PUSH(ompi_cxx_compiler_works)
# There's a few cases here:
#
@@ -66,11 +75,8 @@
# both found a c++ compiler and want the C++ bindings (i.e., either
# case #1 or #3)
-ompi_cxxflags_save="$CXXFLAGS"
-AC_REQUIRE([AC_PROG_CXX])
-AC_REQUIRE([AC_PROG_CXXCPP])
+AC_REQUIRE([_OMPI_SETUP_CXX_COMPILER_HELPER])
BASECXX="`basename $CXX`"
-CXXFLAGS="$ompi_cxxflags_save"
AS_IF([test "x$CXX" = "x"], [CXX=none])
set dummy $CXX
Index: config/ompi_setup_f77.m4
===
--- config/ompi_setup_f77.m4(revision 21794)
+++ config/ompi_setup_f77.m4(working copy)
@@ -41,7 +41,9 @@
# This macro is necessary because PROG_FC is REQUIREd by multiple
# places in SETUP_F90.
AC_DEFUN([OMPI_PROG_F77],[
+ompi_fflags_save="$FFLAGS"
AC_PROG_F77([gfortran g77 f77 xlf frt ifort pgf77 fort77 fl32 af77])
+FFLAGS="$ompi_fflags_save"
])
AC_DEFUN([OMPI_SETUP_F77],[
@@ -58,11 +60,9 @@
# Always run this test, even if fortran isn't wanted so that F77 has
# value for the Fint tests
#
-ompi_fflags_save="$FFLAGS"
# Strangeness in AC2.64 forces us to require a macro that calls
# PROG_FC instead of calling it directly. Weird.
AC_REQUIRE([OMPI_PROG_F77])
-FFLAGS="$ompi_fflags_save"
if test -z "$F77"; then
AC_MSG_WARN([*** Fortran 77 bindings disabled (could not find compile
Re: [OMPI devel] trunk borked -- my fault
On Aug 4, 2009, at 5:50 PM, Jeff Squyres (jsquyres) wrote: Ah -- I see an AC 2.63b release note: ** AC_REQUIRE now detects the case of an outer macro which first expands then later indirectly requires the same inner macro. Previously, Yes, this is exactly what was happening. The AC_REQUIRE's that I added force the tests to be above the respective stdout section headers, which is a little bit of a bummer. I'll fix that. -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
Ah -- I see an AC 2.63b release note: ** AC_REQUIRE now detects the case of an outer macro which first expands then later indirectly requires the same inner macro. Previously, this case led to silent out-of-order expansion (bug present since 2.50); it now issues a syntax warning, and duplicates the expansion of the inner macro to guarantee dependencies have been met. See the manual for advice on how to refactor macros in order to avoid the bug in earlier autoconf versions and avoid increased script size in the current version. This looks related to what I am seeing. /me goes to investigate... On Aug 4, 2009, at 5:47 PM, George Bosilca wrote: Indeed, r21759 solves the problem. ompi compile successfully on Mac OS X with autoconf 2.64. Thanks, george. On Aug 4, 2009, at 17:41 , Jeff Squyres wrote: > On Aug 4, 2009, at 5:37 PM, George Bosilca wrote: > >> I used 2.64 for about a week on a bunch of machines. I never had >> problems with it before... >> >> After checking it turned out that autoconf 2.64 was freshly installed >> on my Mac, so this might be a problem with autoconf 2.64 and MAC OS >> X ... I'll go back to 2.63 until we figure out a way to solve these >> problems. >> > > FWIW, I saw the warnings on Linux as well, and then configure failed > later in spectacular and interesting ways (I didn't let it get to > the build because configure was so borked up -- all the individual > POSIX .h file tests said that the file was present but could not be > compiled because somehow it was stuck trying to compile them with > gfortran (!) instead of gcc). Something changed in AC2.64 with > regards to how they do language REQUIRE'ing, etc. that I don't fully > understand. > > Let me know if the workaround in r21759 works for you. > > -- > Jeff Squyres > jsquy...@cisco.com > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
Indeed, r21759 solves the problem. ompi compile successfully on Mac OS X with autoconf 2.64. Thanks, george. On Aug 4, 2009, at 17:41 , Jeff Squyres wrote: On Aug 4, 2009, at 5:37 PM, George Bosilca wrote: I used 2.64 for about a week on a bunch of machines. I never had problems with it before... After checking it turned out that autoconf 2.64 was freshly installed on my Mac, so this might be a problem with autoconf 2.64 and MAC OS X ... I'll go back to 2.63 until we figure out a way to solve these problems. FWIW, I saw the warnings on Linux as well, and then configure failed later in spectacular and interesting ways (I didn't let it get to the build because configure was so borked up -- all the individual POSIX .h file tests said that the file was present but could not be compiled because somehow it was stuck trying to compile them with gfortran (!) instead of gcc). Something changed in AC2.64 with regards to how they do language REQUIRE'ing, etc. that I don't fully understand. Let me know if the workaround in r21759 works for you. -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] trunk borked -- my fault
On Aug 4, 2009, at 5:37 PM, George Bosilca wrote: I used 2.64 for about a week on a bunch of machines. I never had problems with it before... After checking it turned out that autoconf 2.64 was freshly installed on my Mac, so this might be a problem with autoconf 2.64 and MAC OS X ... I'll go back to 2.63 until we figure out a way to solve these problems. FWIW, I saw the warnings on Linux as well, and then configure failed later in spectacular and interesting ways (I didn't let it get to the build because configure was so borked up -- all the individual POSIX .h file tests said that the file was present but could not be compiled because somehow it was stuck trying to compile them with gfortran (!) instead of gcc). Something changed in AC2.64 with regards to how they do language REQUIRE'ing, etc. that I don't fully understand. Let me know if the workaround in r21759 works for you. -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
https://svn.open-mpi.org/trac/ompi/changeset/21759 seems to make us play well with AC 2.64. To be honest, I'm not sure why this change works, but it does. I'm going to ping Ralf W. and see if he's got any insight here... On Aug 4, 2009, at 5:17 PM, Jeff Squyres (jsquyres) wrote: Checking this further, my C++ changes were r21755. Updating my SVN tree to the commit before that (r21754), I see that AC 2.64 on this tree issues these same warnings, but then configure works and the build seems to proceed as normal. Did you try AC 2.64 before today? If not, I'd advise backing off AC 2.64 and moving back down to AC 2.63 until we can figure those warnings out. They *seem* to be harmless, but I'm not entirely sure. It looks like some things changed 2.63->2.64 with regards to how languages are selected / used within AC 2.64 that break some of the things I did today (perhaps AC 2.64 just got more strict...?). On Aug 4, 2009, at 4:43 PM, Jeff Squyres (jsquyres) wrote: > Doh. I tested with 2.63. I'll check out 2.64 right now... > > > On Aug 4, 2009, at 4:37 PM, George Bosilca wrote: > > > Not completely fixed. With the latest version of autoconf (2.64) I > get > > a bunch of warnings. > > > > configure.ac:449: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded > > before it was required > > ../../lib/autoconf/c.m4:671: AC_LANG_COMPILER(C++) is expanded > from... > > ../../lib/autoconf/lang.m4:315: AC_LANG_COMPILER_REQUIRE is expanded > > from... > > ../../lib/autoconf/general.m4:2735: AC_RUN_IFELSE is expanded > from... > > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded > from... > > config/ompi_check_compiler_works.m4:28: OMPI_CHECK_COMPILER_WORKS is > > expanded from... > > config/ompi_setup_cxx.m4:48: _OMPI_SETUP_CXX_COMPILER is expanded > > from... > > config/ompi_setup_cxx.m4:28: OMPI_SETUP_CXX is expanded from... > > configure.ac:449: the top level > > configure.ac:488: warning: AC_REQUIRE: `AC_PROG_F77' was expanded > > before it was required > > ../../lib/autoconf/fortran.m4:272: AC_LANG_COMPILER(Fortran 77) is > > expanded from... > > config/ompi_setup_f77.m4:35: OMPI_SETUP_F77 is expanded from... > > configure.ac:488: the top level > > configure.ac:603: warning: AC_REQUIRE: `AC_PROG_FC' was expanded > > before it was required > > ../../lib/autoconf/fortran.m4:279: AC_LANG_COMPILER(Fortran) is > > expanded from... > > config/ompi_setup_f90.m4:37: OMPI_SETUP_F90 is expanded from... > > configure.ac:603: the top level > > > >george. > > > > > > On Aug 4, 2009, at 14:49 , Jeff Squyres wrote: > > > > > Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ > > > 21758. Sorry for the interruption... > > > > > > > > > On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: > > > > > >> Doh! > > >> > > >> I committed the "we don't need no stinkin' C++ compiler" changes > > >> this morning after a bunch of testing, but I totally neglected to > > >> test the case *with* a C++ compiler. :-( > > >> > > >> So the trunk is borked at the moment; I'm working on a fix... > > >> > > >> -- > > >> Jeff Squyres > > >> jsquy...@cisco.com > > >> > > >> ___ > > >> devel mailing list > > >> de...@open-mpi.org > > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > > > > -- > > > Jeff Squyres > > > jsquy...@cisco.com > > > > > > ___ > > > devel mailing list > > > de...@open-mpi.org > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > -- > Jeff Squyres > jsquy...@cisco.com > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
I used 2.64 for about a week on a bunch of machines. I never had problems with it before... After checking it turned out that autoconf 2.64 was freshly installed on my Mac, so this might be a problem with autoconf 2.64 and MAC OS X ... I'll go back to 2.63 until we figure out a way to solve these problems. george. On Aug 4, 2009, at 17:17 , Jeff Squyres wrote: Checking this further, my C++ changes were r21755. Updating my SVN tree to the commit before that (r21754), I see that AC 2.64 on this tree issues these same warnings, but then configure works and the build seems to proceed as normal. Did you try AC 2.64 before today? If not, I'd advise backing off AC 2.64 and moving back down to AC 2.63 until we can figure those warnings out. They *seem* to be harmless, but I'm not entirely sure. It looks like some things changed 2.63->2.64 with regards to how languages are selected / used within AC 2.64 that break some of the things I did today (perhaps AC 2.64 just got more strict...?). On Aug 4, 2009, at 4:43 PM, Jeff Squyres (jsquyres) wrote: Doh. I tested with 2.63. I'll check out 2.64 right now... On Aug 4, 2009, at 4:37 PM, George Bosilca wrote: > Not completely fixed. With the latest version of autoconf (2.64) I get > a bunch of warnings. > > configure.ac:449: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded > before it was required > ../../lib/autoconf/c.m4:671: AC_LANG_COMPILER(C++) is expanded from... > ../../lib/autoconf/lang.m4:315: AC_LANG_COMPILER_REQUIRE is expanded > from... > ../../lib/autoconf/general.m4:2735: AC_RUN_IFELSE is expanded from... > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... > config/ompi_check_compiler_works.m4:28: OMPI_CHECK_COMPILER_WORKS is > expanded from... > config/ompi_setup_cxx.m4:48: _OMPI_SETUP_CXX_COMPILER is expanded > from... > config/ompi_setup_cxx.m4:28: OMPI_SETUP_CXX is expanded from... > configure.ac:449: the top level > configure.ac:488: warning: AC_REQUIRE: `AC_PROG_F77' was expanded > before it was required > ../../lib/autoconf/fortran.m4:272: AC_LANG_COMPILER(Fortran 77) is > expanded from... > config/ompi_setup_f77.m4:35: OMPI_SETUP_F77 is expanded from... > configure.ac:488: the top level > configure.ac:603: warning: AC_REQUIRE: `AC_PROG_FC' was expanded > before it was required > ../../lib/autoconf/fortran.m4:279: AC_LANG_COMPILER(Fortran) is > expanded from... > config/ompi_setup_f90.m4:37: OMPI_SETUP_F90 is expanded from... > configure.ac:603: the top level > >george. > > > On Aug 4, 2009, at 14:49 , Jeff Squyres wrote: > > > Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ > > 21758. Sorry for the interruption... > > > > > > On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: > > > >> Doh! > >> > >> I committed the "we don't need no stinkin' C++ compiler" changes > >> this morning after a bunch of testing, but I totally neglected to > >> test the case *with* a C++ compiler. :-( > >> > >> So the trunk is borked at the moment; I'm working on a fix... > >> > >> -- > >> Jeff Squyres > >> jsquy...@cisco.com > >> > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] trunk borked -- my fault
Checking this further, my C++ changes were r21755. Updating my SVN tree to the commit before that (r21754), I see that AC 2.64 on this tree issues these same warnings, but then configure works and the build seems to proceed as normal. Did you try AC 2.64 before today? If not, I'd advise backing off AC 2.64 and moving back down to AC 2.63 until we can figure those warnings out. They *seem* to be harmless, but I'm not entirely sure. It looks like some things changed 2.63->2.64 with regards to how languages are selected / used within AC 2.64 that break some of the things I did today (perhaps AC 2.64 just got more strict...?). On Aug 4, 2009, at 4:43 PM, Jeff Squyres (jsquyres) wrote: Doh. I tested with 2.63. I'll check out 2.64 right now... On Aug 4, 2009, at 4:37 PM, George Bosilca wrote: > Not completely fixed. With the latest version of autoconf (2.64) I get > a bunch of warnings. > > configure.ac:449: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded > before it was required > ../../lib/autoconf/c.m4:671: AC_LANG_COMPILER(C++) is expanded from... > ../../lib/autoconf/lang.m4:315: AC_LANG_COMPILER_REQUIRE is expanded > from... > ../../lib/autoconf/general.m4:2735: AC_RUN_IFELSE is expanded from... > ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... > ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... > ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... > config/ompi_check_compiler_works.m4:28: OMPI_CHECK_COMPILER_WORKS is > expanded from... > config/ompi_setup_cxx.m4:48: _OMPI_SETUP_CXX_COMPILER is expanded > from... > config/ompi_setup_cxx.m4:28: OMPI_SETUP_CXX is expanded from... > configure.ac:449: the top level > configure.ac:488: warning: AC_REQUIRE: `AC_PROG_F77' was expanded > before it was required > ../../lib/autoconf/fortran.m4:272: AC_LANG_COMPILER(Fortran 77) is > expanded from... > config/ompi_setup_f77.m4:35: OMPI_SETUP_F77 is expanded from... > configure.ac:488: the top level > configure.ac:603: warning: AC_REQUIRE: `AC_PROG_FC' was expanded > before it was required > ../../lib/autoconf/fortran.m4:279: AC_LANG_COMPILER(Fortran) is > expanded from... > config/ompi_setup_f90.m4:37: OMPI_SETUP_F90 is expanded from... > configure.ac:603: the top level > >george. > > > On Aug 4, 2009, at 14:49 , Jeff Squyres wrote: > > > Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ > > 21758. Sorry for the interruption... > > > > > > On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: > > > >> Doh! > >> > >> I committed the "we don't need no stinkin' C++ compiler" changes > >> this morning after a bunch of testing, but I totally neglected to > >> test the case *with* a C++ compiler. :-( > >> > >> So the trunk is borked at the moment; I'm working on a fix... > >> > >> -- > >> Jeff Squyres > >> jsquy...@cisco.com > >> > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
Doh. I tested with 2.63. I'll check out 2.64 right now... On Aug 4, 2009, at 4:37 PM, George Bosilca wrote: Not completely fixed. With the latest version of autoconf (2.64) I get a bunch of warnings. configure.ac:449: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded before it was required ../../lib/autoconf/c.m4:671: AC_LANG_COMPILER(C++) is expanded from... ../../lib/autoconf/lang.m4:315: AC_LANG_COMPILER_REQUIRE is expanded from... ../../lib/autoconf/general.m4:2735: AC_RUN_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... config/ompi_check_compiler_works.m4:28: OMPI_CHECK_COMPILER_WORKS is expanded from... config/ompi_setup_cxx.m4:48: _OMPI_SETUP_CXX_COMPILER is expanded from... config/ompi_setup_cxx.m4:28: OMPI_SETUP_CXX is expanded from... configure.ac:449: the top level configure.ac:488: warning: AC_REQUIRE: `AC_PROG_F77' was expanded before it was required ../../lib/autoconf/fortran.m4:272: AC_LANG_COMPILER(Fortran 77) is expanded from... config/ompi_setup_f77.m4:35: OMPI_SETUP_F77 is expanded from... configure.ac:488: the top level configure.ac:603: warning: AC_REQUIRE: `AC_PROG_FC' was expanded before it was required ../../lib/autoconf/fortran.m4:279: AC_LANG_COMPILER(Fortran) is expanded from... config/ompi_setup_f90.m4:37: OMPI_SETUP_F90 is expanded from... configure.ac:603: the top level george. On Aug 4, 2009, at 14:49 , Jeff Squyres wrote: > Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ > 21758. Sorry for the interruption... > > > On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: > >> Doh! >> >> I committed the "we don't need no stinkin' C++ compiler" changes >> this morning after a bunch of testing, but I totally neglected to >> test the case *with* a C++ compiler. :-( >> >> So the trunk is borked at the moment; I'm working on a fix... >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > jsquy...@cisco.com > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] trunk borked -- my fault
Not completely fixed. With the latest version of autoconf (2.64) I get a bunch of warnings. configure.ac:449: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded before it was required ../../lib/autoconf/c.m4:671: AC_LANG_COMPILER(C++) is expanded from... ../../lib/autoconf/lang.m4:315: AC_LANG_COMPILER_REQUIRE is expanded from... ../../lib/autoconf/general.m4:2735: AC_RUN_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... config/ompi_check_compiler_works.m4:28: OMPI_CHECK_COMPILER_WORKS is expanded from... config/ompi_setup_cxx.m4:48: _OMPI_SETUP_CXX_COMPILER is expanded from... config/ompi_setup_cxx.m4:28: OMPI_SETUP_CXX is expanded from... configure.ac:449: the top level configure.ac:488: warning: AC_REQUIRE: `AC_PROG_F77' was expanded before it was required ../../lib/autoconf/fortran.m4:272: AC_LANG_COMPILER(Fortran 77) is expanded from... config/ompi_setup_f77.m4:35: OMPI_SETUP_F77 is expanded from... configure.ac:488: the top level configure.ac:603: warning: AC_REQUIRE: `AC_PROG_FC' was expanded before it was required ../../lib/autoconf/fortran.m4:279: AC_LANG_COMPILER(Fortran) is expanded from... config/ompi_setup_f90.m4:37: OMPI_SETUP_F90 is expanded from... configure.ac:603: the top level george. On Aug 4, 2009, at 14:49 , Jeff Squyres wrote: Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ 21758. Sorry for the interruption... On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: Doh! I committed the "we don't need no stinkin' C++ compiler" changes this morning after a bunch of testing, but I totally neglected to test the case *with* a C++ compiler. :-( So the trunk is borked at the moment; I'm working on a fix... -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] trunk borked -- my fault
Should be fixed in https://svn.open-mpi.org/trac/ompi/changeset/ 21758. Sorry for the interruption... On Aug 4, 2009, at 10:24 AM, Jeff Squyres wrote: Doh! I committed the "we don't need no stinkin' C++ compiler" changes this morning after a bunch of testing, but I totally neglected to test the case *with* a C++ compiler. :-( So the trunk is borked at the moment; I'm working on a fix... -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com
[OMPI devel] trunk borked -- my fault
Doh! I committed the "we don't need no stinkin' C++ compiler" changes this morning after a bunch of testing, but I totally neglected to test the case *with* a C++ compiler. :-( So the trunk is borked at the moment; I'm working on a fix... -- Jeff Squyres jsquy...@cisco.com
Re: [OMPI devel] Trunk borked
Hi Tim, the configure script of the vt-integration don't check whether MPI I/O is disabled, so the VT's MPI_File_* wrapper functions will be built. A quick solution for this problem should be to add the option "--with-contrib-vt-flags=--without-mpi-io" to the configure script. I'm working on a better solution... To disable the vt-integration completely add the following option to the configure script: configure --enable-contrib-no-build=vt ... Sorry again for this trouble! Regards, Matthias On Di, 2008-01-29 at 07:37 -0500, Tim Prins wrote: > We have run into another issue with the vt integration. Configuring with > '--disable-mpi-io' results in: > > vt_mpiwrap.c:3565: error: `fh' undeclared (first use in this function) > vt_mpiwrap.c:3565: error: `buf' undeclared (first use in this function) > vt_mpiwrap.c:3565: error: `count' undeclared (first use in this function) > vt_mpiwrap.c:3565: error: `datatype' undeclared (first use in this function) > vt_mpiwrap.c:3565: error: `status' undeclared (first use in this function) > vt_mpiwrap.c: At top level: > vt_mpiwrap.c:3582: error: syntax error before "fh" > vt_mpiwrap.c: In function `MPI_File_seek_shared': > vt_mpiwrap.c:3596: error: `fh' undeclared (first use in this function) > vt_mpiwrap.c:3596: error: `offset' undeclared (first use in this function) > vt_mpiwrap.c:3596: error: `whence' undeclared (first use in this function) > vt_mpiwrap.c: At top level: > vt_mpiwrap.c:3613: error: syntax error before "fh" > vt_mpiwrap.c: In function `MPI_File_write_ordered': > vt_mpiwrap.c:3629: error: `fh' undeclared (first use in this function) > vt_mpiwrap.c:3629: error: `buf' undeclared (first use in this function) > vt_mpiwrap.c:3629: error: `count' undeclared (first use in this function) > vt_mpiwrap.c:3629: error: `datatype' undeclared (first use in this function) > vt_mpiwrap.c:3629: error: `status' undeclared (first use in this function) > vt_mpiwrap.c: At top level: > vt_mpiwrap.c:3646: error: syntax error before "fh" > vt_mpiwrap.c: In function `MPI_File_write_shared': > vt_mpiwrap.c:3662: error: `fh' undeclared (first use in this function) > vt_mpiwrap.c:3662: error: `buf' undeclared (first use in this function) > vt_mpiwrap.c:3662: error: `count' undeclared (first use in this function) > vt_mpiwrap.c:3662: error: `datatype' undeclared (first use in this function) > vt_mpiwrap.c:3662: error: `status' undeclared (first use in this function) > rm -f libvt.a > mv -f .deps/libvt_mpi_a-vt_user_region.Tpo > .deps/libvt_mpi_a-vt_user_region.Po > ar cru libvt.a vt_comp_gnu.o vt_memhook.o vt_memreg.o vt_iowrap.o > vt_iowrap_helper.o > rfg_regions.o rfg_filter.o rfg_groups.o vt_env.o vt_error.o vt_metmap.o > vt_otf_gen.o vt_otf_sum.o > vt_otf_trc.o vt_pform_linux.o vt_pomp_base.o vt_strdup.o vt_thrd.o > vt_user_comment.o > vt_user_count.o vt_user_region.o pomp_fwrapper_base.o > mv -f .deps/libvt_mpi_a-vt_mpireq.Tpo .deps/libvt_mpi_a-vt_mpireq.Po > vt_fmpiwrap.c: In function `vt_mpi_file_close_f': > vt_fmpiwrap.c:2080: error: `MPI_File' undeclared (first use in this > function) > vt_fmpiwrap.c:2080: error: (Each undeclared identifier is reported only once > vt_fmpiwrap.c:2080: error: for each function it appears in.) > vt_fmpiwrap.c:2080: error: syntax error before "l_fh" > vt_fmpiwrap.c:2081: error: `l_fh' undeclared (first use in this function) > vt_fmpiwrap.c: In function `vt_mpi_file_open_f': > vt_fmpiwrap.c:2095: error: `MPI_File' undeclared (first use in this > function) > vt_fmpiwrap.c:2095: error: syntax error before "l_fh" > vt_fmpiwrap.c:2103: error: `l_fh' undeclared (first use in this function) > make[5]: *** [libvt_mpi_a-vt_mpiwrap.o] Error 1 > make[5]: *** Waiting for unfinished jobs > ranlib libvt.a > make[5]: *** Waiting for unfinished jobs > make[5]: *** [libvt_fmpi_a-vt_fmpiwrap.o] Error 1 > mv -f .deps/libvt_mpi_a-vt_iowrap.Tpo .deps/libvt_mpi_a-vt_iowrap.Po > make[5]: Leaving directory > `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt/vtlib' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory > `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi' > make: *** [all-recursive] Error 1 > > > Sorry for the messy output, we use make -j 6. > > Thanks, > > Tim > > Andreas Knüpfer wrote: > > On Tuesday 29 January 2008, George Bosilca wrote: > >> Loo
Re: [OMPI devel] Trunk borked
We have run into another issue with the vt integration. Configuring with '--disable-mpi-io' results in: vt_mpiwrap.c:3565: error: `fh' undeclared (first use in this function) vt_mpiwrap.c:3565: error: `buf' undeclared (first use in this function) vt_mpiwrap.c:3565: error: `count' undeclared (first use in this function) vt_mpiwrap.c:3565: error: `datatype' undeclared (first use in this function) vt_mpiwrap.c:3565: error: `status' undeclared (first use in this function) vt_mpiwrap.c: At top level: vt_mpiwrap.c:3582: error: syntax error before "fh" vt_mpiwrap.c: In function `MPI_File_seek_shared': vt_mpiwrap.c:3596: error: `fh' undeclared (first use in this function) vt_mpiwrap.c:3596: error: `offset' undeclared (first use in this function) vt_mpiwrap.c:3596: error: `whence' undeclared (first use in this function) vt_mpiwrap.c: At top level: vt_mpiwrap.c:3613: error: syntax error before "fh" vt_mpiwrap.c: In function `MPI_File_write_ordered': vt_mpiwrap.c:3629: error: `fh' undeclared (first use in this function) vt_mpiwrap.c:3629: error: `buf' undeclared (first use in this function) vt_mpiwrap.c:3629: error: `count' undeclared (first use in this function) vt_mpiwrap.c:3629: error: `datatype' undeclared (first use in this function) vt_mpiwrap.c:3629: error: `status' undeclared (first use in this function) vt_mpiwrap.c: At top level: vt_mpiwrap.c:3646: error: syntax error before "fh" vt_mpiwrap.c: In function `MPI_File_write_shared': vt_mpiwrap.c:3662: error: `fh' undeclared (first use in this function) vt_mpiwrap.c:3662: error: `buf' undeclared (first use in this function) vt_mpiwrap.c:3662: error: `count' undeclared (first use in this function) vt_mpiwrap.c:3662: error: `datatype' undeclared (first use in this function) vt_mpiwrap.c:3662: error: `status' undeclared (first use in this function) rm -f libvt.a mv -f .deps/libvt_mpi_a-vt_user_region.Tpo .deps/libvt_mpi_a-vt_user_region.Po ar cru libvt.a vt_comp_gnu.o vt_memhook.o vt_memreg.o vt_iowrap.o vt_iowrap_helper.o rfg_regions.o rfg_filter.o rfg_groups.o vt_env.o vt_error.o vt_metmap.o vt_otf_gen.o vt_otf_sum.o vt_otf_trc.o vt_pform_linux.o vt_pomp_base.o vt_strdup.o vt_thrd.o vt_user_comment.o vt_user_count.o vt_user_region.o pomp_fwrapper_base.o mv -f .deps/libvt_mpi_a-vt_mpireq.Tpo .deps/libvt_mpi_a-vt_mpireq.Po vt_fmpiwrap.c: In function `vt_mpi_file_close_f': vt_fmpiwrap.c:2080: error: `MPI_File' undeclared (first use in this function) vt_fmpiwrap.c:2080: error: (Each undeclared identifier is reported only once vt_fmpiwrap.c:2080: error: for each function it appears in.) vt_fmpiwrap.c:2080: error: syntax error before "l_fh" vt_fmpiwrap.c:2081: error: `l_fh' undeclared (first use in this function) vt_fmpiwrap.c: In function `vt_mpi_file_open_f': vt_fmpiwrap.c:2095: error: `MPI_File' undeclared (first use in this function) vt_fmpiwrap.c:2095: error: syntax error before "l_fh" vt_fmpiwrap.c:2103: error: `l_fh' undeclared (first use in this function) make[5]: *** [libvt_mpi_a-vt_mpiwrap.o] Error 1 make[5]: *** Waiting for unfinished jobs ranlib libvt.a make[5]: *** Waiting for unfinished jobs make[5]: *** [libvt_fmpi_a-vt_fmpiwrap.o] Error 1 mv -f .deps/libvt_mpi_a-vt_iowrap.Tpo .deps/libvt_mpi_a-vt_iowrap.Po make[5]: Leaving directory `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt/vtlib' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt' make[3]: *** [all] Error 2 make[3]: Leaving directory `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt/vt' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi/contrib/vt' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/san/homedirs/mpiteam/mtt-runs/odin/20080128-Nightly/pb_5/installs/VUuZ/src/openmpi-1.3a1r17289/ompi' make: *** [all-recursive] Error 1 Sorry for the messy output, we use make -j 6. Thanks, Tim Andreas Knüpfer wrote: On Tuesday 29 January 2008, George Bosilca wrote: Look like VT do not correctly compute dependencies. A static build will fails if libz.a is not installed on the system. /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make[5]: *** [vtfilter] Error 1 george. this issue should be fixed now, even without additional configure parameters. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Trunk borked
On Tuesday 29 January 2008, George Bosilca wrote: > Look like VT do not correctly compute dependencies. A static build > will fails if libz.a is not installed on the system. > > /usr/bin/ld: cannot find -lz > collect2: ld returned 1 exit status > make[5]: *** [vtfilter] Error 1 > >george. > this issue should be fixed now, even without additional configure parameters. -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 pgpwjpFWgBj09.pgp Description: PGP signature
Re: [OMPI devel] Trunk borked
On Di, 2008-01-29 at 02:53 -0500, Aurélien Bouteiller wrote: > DSO build also fail. > > ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5: > warning: "VT_BFD" is not defined > ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5: > warning: "VT_BFD" is not defined Fixed. > /usr/bin/ld: cannot find -lz > collect2: ld returned 1 exit status > make[6]: *** [vtfilter] Error 1 > Please add the configure option --with-contrib-vt-flags="--with-otf-flags=--without-zlib --with-otf-lib=-lotf" This option will disable the zlib support of VampirTrace. I'm working on a correct solution for this problem. Sorry for the trouble which comes with the VT integration... :-( > Le 29 janv. 08 à 01:51, George Bosilca a écrit : > > > Look like VT do not correctly compute dependencies. A static build > > will fails if libz.a is not installed on the system. > > > > /usr/bin/ld: cannot find -lz > > collect2: ld returned 1 exit status > > make[5]: *** [vtfilter] Error 1 > > > > george. > > > > On Jan 28, 2008, at 12:37 PM, Matthias Jurenz wrote: > > > >> Hello, > >> > >> this problem should be fixed now... > >> It seems that the symbol '__pos' is not available on every > >> platform. This isn't a problem, because > >> it's only used for a debug control message. > >> > >> Regards, > >> Matthias > >> > >> > >> On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote: > >>> > >>> Doh - this is Solaris on x86? I think Terry said Solaris/sparc was > >>> tested... > >>> > >>> VT guys -- can you check out what's going on? > >>> > >>> > >>> > >>> On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote: > >>> > >>> > On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: > >>> > > >>> >> We seem to have a problem on the trunk this morning. I am > >>> building > >>> >> on a > >>> > > >>> > There are more errors: > >>> > > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > >>> > `fsetpos': > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: > >>> request > >>> > for member `__pos' in something not a structure or union > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > >>> > `fsetpos64': > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: > >>> request > >>> > for member `__pos' in something not a structure or union > >>> > gmake[5]: *** [vt_iowrap.o] Error 1 > >>> > gmake[5]: Leaving directory > >>> > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > >>> > `fsetpos': > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: > >>> request > >>> > for member `__pos' in something not a structure or union > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > >>> > `fsetpos64': > >>> > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: > >>> request > >>> > for member `__pos' in something not a structure or union > >>> > gmake[5]: *** [vt_iowrap.o] Error 1 > >>> > gmake[5]: Leaving directory > >>> > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > >>> > > >>> > > >>> > Just my $0.02 > >>> > > >>> > -- > >>> > Cluster and Metacomputing Working Group > >>> > Friedrich-Schiller-Universität Jena, Germany > >>> > > >>> > private: http://adi.thur.de > >>> > ___ > >>> > devel mailing list > >>> > de...@open-mpi.org > >>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> > >>> > >> -- > >> Matthias Jurenz, > >> Center for Information Services and > >> High Performance Computing (ZIH), TU Dresden, > >> Willersbau A106, Zellescher Weg 12, 01062 Dresden > >> phone +49-351-463-31945, fax +49-351-463-37773 > >> ___ > >> devel mailing list > >> de...@open-mpi.org > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Matthias Jurenz, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A106, Zellescher Weg 12, 01062 Dresden phone +49-351-463-31945, fax +49-351-463-37773 smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] Trunk borked
DSO build also fail. ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5: warning: "VT_BFD" is not defined ../../../../../../trunk/ompi/contrib/vt/vt/vtlib/vt_comp_gnu.c:312:5: warning: "VT_BFD" is not defined /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make[6]: *** [vtfilter] Error 1 Le 29 janv. 08 à 01:51, George Bosilca a écrit : Look like VT do not correctly compute dependencies. A static build will fails if libz.a is not installed on the system. /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make[5]: *** [vtfilter] Error 1 george. On Jan 28, 2008, at 12:37 PM, Matthias Jurenz wrote: Hello, this problem should be fixed now... It seems that the symbol '__pos' is not available on every platform. This isn't a problem, because it's only used for a debug control message. Regards, Matthias On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote: Doh - this is Solaris on x86? I think Terry said Solaris/sparc was tested... VT guys -- can you check out what's going on? On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote: > On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: > >> We seem to have a problem on the trunk this morning. I am building >> on a > > There are more errors: > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > for member `__pos' in something not a structure or union > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos64': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > for member `__pos' in something not a structure or union > gmake[5]: *** [vt_iowrap.o] Error 1 > gmake[5]: Leaving directory > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > for member `__pos' in something not a structure or union > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos64': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > for member `__pos' in something not a structure or union > gmake[5]: *** [vt_iowrap.o] Error 1 > gmake[5]: Leaving directory > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > > > Just my $0.02 > > -- > Cluster and Metacomputing Working Group > Friedrich-Schiller-Universität Jena, Germany > > private: http://adi.thur.de > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Matthias Jurenz, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A106, Zellescher Weg 12, 01062 Dresden phone +49-351-463-31945, fax +49-351-463-37773 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Trunk borked
Look like VT do not correctly compute dependencies. A static build will fails if libz.a is not installed on the system. /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make[5]: *** [vtfilter] Error 1 george. On Jan 28, 2008, at 12:37 PM, Matthias Jurenz wrote: Hello, this problem should be fixed now... It seems that the symbol '__pos' is not available on every platform. This isn't a problem, because it's only used for a debug control message. Regards, Matthias On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote: Doh - this is Solaris on x86? I think Terry said Solaris/sparc was tested... VT guys -- can you check out what's going on? On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote: > On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: > >> We seem to have a problem on the trunk this morning. I am building >> on a > > There are more errors: > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > for member `__pos' in something not a structure or union > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos64': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > for member `__pos' in something not a structure or union > gmake[5]: *** [vt_iowrap.o] Error 1 > gmake[5]: Leaving directory > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > for member `__pos' in something not a structure or union > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > `fsetpos64': > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > for member `__pos' in something not a structure or union > gmake[5]: *** [vt_iowrap.o] Error 1 > gmake[5]: Leaving directory > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > > > Just my $0.02 > > -- > Cluster and Metacomputing Working Group > Friedrich-Schiller-Universität Jena, Germany > > private: http://adi.thur.de > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Matthias Jurenz, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A106, Zellescher Weg 12, 01062 Dresden phone +49-351-463-31945, fax +49-351-463-37773 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] Trunk borked
Hello, this problem should be fixed now... It seems that the symbol '__pos' is not available on every platform. This isn't a problem, because it's only used for a debug control message. Regards, Matthias On Mo, 2008-01-28 at 09:41 -0500, Jeff Squyres wrote: > Doh - this is Solaris on x86? I think Terry said Solaris/sparc was > tested... > > VT guys -- can you check out what's going on? > > > > On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote: > > > On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: > > > >> We seem to have a problem on the trunk this morning. I am building > >> on a > > > > There are more errors: > > > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > > `fsetpos': > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > > for member `__pos' in something not a structure or union > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > > `fsetpos64': > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > > for member `__pos' in something not a structure or union > > gmake[5]: *** [vt_iowrap.o] Error 1 > > gmake[5]: Leaving directory > > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > > `fsetpos': > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request > > for member `__pos' in something not a structure or union > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function > > `fsetpos64': > > /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request > > for member `__pos' in something not a structure or union > > gmake[5]: *** [vt_iowrap.o] Error 1 > > gmake[5]: Leaving directory > > `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' > > > > > > Just my $0.02 > > > > -- > > Cluster and Metacomputing Working Group > > Friedrich-Schiller-Universität Jena, Germany > > > > private: http://adi.thur.de > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > -- Matthias Jurenz, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A106, Zellescher Weg 12, 01062 Dresden phone +49-351-463-31945, fax +49-351-463-37773 smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] Trunk borked
Doh - this is Solaris on x86? I think Terry said Solaris/sparc was tested... VT guys -- can you check out what's going on? On Jan 28, 2008, at 9:36 AM, Adrian Knoth wrote: On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: We seem to have a problem on the trunk this morning. I am building on a There are more errors: /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request for member `__pos' in something not a structure or union /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos64': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request for member `__pos' in something not a structure or union gmake[5]: *** [vt_iowrap.o] Error 1 gmake[5]: Leaving directory `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request for member `__pos' in something not a structure or union /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos64': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request for member `__pos' in something not a structure or union gmake[5]: *** [vt_iowrap.o] Error 1 gmake[5]: Leaving directory `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' Just my $0.02 -- Cluster and Metacomputing Working Group Friedrich-Schiller-Universität Jena, Germany private: http://adi.thur.de ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] Trunk borked
Doh -- sorry about that. r17282 removes the erroneous #if. On Jan 28, 2008, at 9:26 AM, Ralph H Castain wrote: We seem to have a problem on the trunk this morning. I am building on a platform with the following configuration: with_threads=no enable_dlopen=no enable_pty_support=no with_tm=/opt/PBS LDFLAGS=-L/opt/PBS/lib64 with_openib=/opt/ofed with_memory_manager=no enable_mem_debug=yes enable_mem_profile=no enable_debug_symbols=yes enable_binaries=yes with_devel_headers=yes enable_heterogeneous=no enable_picky=yes The compile errors out in the OpenIB BTL with the following error: btl_openib_proc.c: In function `mca_btl_openib_proc_create': btl_openib_proc.c:159: error: `i' undeclared (first use in this function) btl_openib_proc.c:159: error: (Each undeclared identifier is reported only once btl_openib_proc.c:159: error: for each function it appears in.) make[2]: *** [btl_openib_proc.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 When I look at the code, the problem is the following #if: #if !defined(WORDS_BIGENDIAN) && OMPI_ENABLE_HETEROGENEOUS_SUPPORT size_t i; #endif Yet the code will ALWAYS use that variable to unpack all the ports. I removed the #if to clear the problem, but before committing the change, I wanted to ask why someone thought this test needed to be in the code. Should the entire loop unpacking all the ports be similarly protected, or was the protection around the variable declaration simply an error? Thanks Ralph ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] Trunk borked
On Mon, Jan 28, 2008 at 07:26:56AM -0700, Ralph H Castain wrote: > We seem to have a problem on the trunk this morning. I am building on a There are more errors: /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request for member `__pos' in something not a structure or union /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos64': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request for member `__pos' in something not a structure or union gmake[5]: *** [vt_iowrap.o] Error 1 gmake[5]: Leaving directory `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:850: error: request for member `__pos' in something not a structure or union /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c: In function `fsetpos64': /tmp/ompi/src/ompi/contrib/vt/vt/vtlib/vt_iowrap.c:876: error: request for member `__pos' in something not a structure or union gmake[5]: *** [vt_iowrap.o] Error 1 gmake[5]: Leaving directory `/tmp/ompi/build/SunOS-i86pc/ompi/ompi/contrib/vt/vt/vtlib' Just my $0.02 -- Cluster and Metacomputing Working Group Friedrich-Schiller-Universität Jena, Germany private: http://adi.thur.de
[OMPI devel] Trunk borked
We seem to have a problem on the trunk this morning. I am building on a platform with the following configuration: with_threads=no enable_dlopen=no enable_pty_support=no with_tm=/opt/PBS LDFLAGS=-L/opt/PBS/lib64 with_openib=/opt/ofed with_memory_manager=no enable_mem_debug=yes enable_mem_profile=no enable_debug_symbols=yes enable_binaries=yes with_devel_headers=yes enable_heterogeneous=no enable_picky=yes The compile errors out in the OpenIB BTL with the following error: btl_openib_proc.c: In function `mca_btl_openib_proc_create': btl_openib_proc.c:159: error: `i' undeclared (first use in this function) btl_openib_proc.c:159: error: (Each undeclared identifier is reported only once btl_openib_proc.c:159: error: for each function it appears in.) make[2]: *** [btl_openib_proc.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 When I look at the code, the problem is the following #if: #if !defined(WORDS_BIGENDIAN) && OMPI_ENABLE_HETEROGENEOUS_SUPPORT size_t i; #endif Yet the code will ALWAYS use that variable to unpack all the ports. I removed the #if to clear the problem, but before committing the change, I wanted to ask why someone thought this test needed to be in the code. Should the entire loop unpacking all the ports be similarly protected, or was the protection around the variable declaration simply an error? Thanks Ralph
[OMPI devel] Trunk borked?
Yo all I've been playing with the trunk today and found it appears to be broken for comm_spawn. I'm getting two types of errors, perhaps related: 1. if everything is being done on localhost, I do not see any of the IO from the child process. Mpirun executes and completes cleanly, however. Because, the spawn'd child terminates so quickly, I haven't been able to positively confirm it is actually running - though I have some indication that it is. 2. if running on multiple hosts, I see the output from the child processes, but mpirun "hangs" in MPI_Comm_disconnect. A ctrl-C is able to kill the entire job. Any ideas on what might have happened? This was all working not that long ago...can't swear to an r-level at the moment, but am hoping someone has an idea before I start having to blindly work backwards to find out what broke it. Thanks Ralph
