Re: [OMPI devel] trunk borked -- my fault

2009-08-11 Thread Jeff Squyres
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
 # 

Re: [OMPI devel] trunk borked -- my fault

2009-08-11 Thread Ralf Wildenhues
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 

Re: [OMPI devel] trunk borked -- my fault

2009-08-04 Thread Jeff Squyres

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

2009-08-04 Thread Jeff Squyres

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

2009-08-04 Thread George Bosilca
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

2009-08-04 Thread Jeff Squyres

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

2009-08-04 Thread Jeff Squyres
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

2009-08-04 Thread George Bosilca
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

2009-08-04 Thread Jeff Squyres
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

2009-08-04 Thread Jeff Squyres

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

2009-08-04 Thread George Bosilca
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

2009-08-04 Thread Jeff Squyres
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

2009-08-04 Thread Jeff Squyres

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

2008-01-29 Thread Matthias Jurenz
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:
> >> 

Re: [OMPI devel] Trunk borked

2008-01-29 Thread Tim Prins
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

2008-01-29 Thread Andreas Knüpfer
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

2008-01-29 Thread Matthias Jurenz
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

2008-01-29 Thread Aurélien Bouteiller

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

2008-01-29 Thread George Bosilca
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

2008-01-28 Thread Matthias Jurenz
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

2008-01-28 Thread Jeff Squyres
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

2008-01-28 Thread Jeff Squyres

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

2008-01-28 Thread Adrian Knoth
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

2008-01-28 Thread Ralph H Castain
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?

2007-08-06 Thread Ralph H Castain
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