Re: [OMPI devel] Memchecker: breaks trunk again

[Jeff Squyres]

See https://svn.open-mpi.org/trac/ompi/ticket/1276.

On Apr 21, 2008, at 6:44 PM, Rainer Keller wrote:


Hi Jeff and Ralph,
On Monday 21 April 2008 16:48, Jeff Squyres wrote:

Ah, I see what's happening.

The opal/mca/memchecker/valgrind/configure.m4 file is using "want
memchecker" to indicate that you want valgrind support.  I think that
these should be two different issues.  I'll file a ticket.


In opal/mca/memchecker/valgrind/configure.m4, we test
   if test "$WANT_MEMCHECKER" = "1" ; then
...
   else
   happy=0  # none_needed
   happy_value=0# none_needed
   memchecker_valgrind_happy=0  # This should suffice to get rid  
of the

component
   should_build=2
   want_component=0
   fi

We have been looking into other syntaxes to deselect the component,  
but did

not find any.

Is there a better way within one plugin of a component to deselect  
it (or

rather say, that none of the components should be checked for?)




Additionally, for the platform file overriding the configure command
line; I *think* that that's expected behavior -- the platform file is
a tradeoff and had to be implemented as an ugly hack because of the
way autoconf parses command line flags (IIRC, the command line flags
are parsed and *then* the platform file is parsed -- I don't think
there was another way to do it).  Perhaps that behavior should be
documented.

What's the ticket#?

Sorry, if this is causing You trouble, Ralph.

CU,
Rainer



On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote:

On 4/21/08 8:10 AM, "Jeff Squyres"  wrote:

Hmm.  I do not have this problem on OS X (where I do not have
Valgrind
installed) as of this morning's trunk.  configure correctly
determines
that valgrind is not present and therefore continues on:

--- MCA component memchecker:valgrind (m4 configuration macro)
checking for MCA component memchecker:valgrind compile mode...  
static

checking if MCA component memchecker:valgrind can compile... no

...etc.

Note that your message indicates that configure thinks that  
valgrind

support was explicitly requested.  In this case, configure thinks,
"you explicitly requested it, I cannot provide it, so I should  
abort

rather than give unexpected results."


I know that - but I am not explicitly requesting it. In fact, I
explicitly
put --without-valgrind, to no effect.

Here is what I have discovered may be the source of the problem. I  
had

inserted a enable_memchecker=yes line in my platform file. This
apparently
has the unfortunate side effect of now requiring valgrind. IMHO,
this should
not be setup that way per my earlier comment about requiring  
debuggers

unless memchecker has absolutely no other way to run - which looking
at the
framework, would not appear to be true.

I then tried still using my platform file, but adding --disable-
memchecker
to the configure line. The disable request was apparently ignored,
at least
as far as the valgrind part of the request is concerned. The build
failed at
the same point.

Removing the enable_memchecker=yes line from my platform file allows
me to
successfully navigate configure.

So it appears to be a combination of memchecker=yes automatically
requiring
valgrind, and the override on the configure line of a param set by a
platform file not working.

I can send you some stuff off-list in a little bit, if you still
need it.


Can you send your full configure output and config.log?

On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote:

As an FYI for anyone similarly afflicted:

The only solution I have found is to gut the file
opal/mca/memchecker/valgrind/configure.m4:

# MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if- 
not-

found])
# ---
AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[

 happy=0  # none_needed
 happy_value=0# none_needed
 memchecker_valgrind_happy=0  # This should suffice to get rid
of the
component
 should_build=2
 want_component=0
])dnl

Nothing else will allow you to build unless you have the valgrind
headers
installed on your machine.

Ralph

On 4/21/08 7:28 AM, "Ralph H Castain"  wrote:
I am finding that the memchecker code is again breaking the  
trunk,
specifically on any machine that does not have valgrind  
installed.

Apparently, memchecker now forces a requirement for valgrind?

Here is what I get:

--- MCA component memchecker:valgrind (m4 configuration macro)
checking for MCA component memchecker:valgrind compile mode...
static
checking checking for the valgrind include directory ... none
needed
checking valgrind/valgrind.h usability... no
checking valgrind/valgrind.h presence... no
checking for valgrind/valgrind.h... no
configure: WARNING: *** Could not find valgrind header files, as
valgrind
support was requested
configure: error: *** Cannot continue


Could somebody please fix this? I thought we had decided many  

Re: [OMPI devel] Memchecker: breaks trunk again

[Rainer Keller]

Hi Jeff and Ralph,
On Monday 21 April 2008 16:48, Jeff Squyres wrote:
> Ah, I see what's happening.
>
> The opal/mca/memchecker/valgrind/configure.m4 file is using "want
> memchecker" to indicate that you want valgrind support.  I think that
> these should be two different issues.  I'll file a ticket.

In opal/mca/memchecker/valgrind/configure.m4, we test 
if test "$WANT_MEMCHECKER" = "1" ; then
...
else
happy=0  # none_needed
happy_value=0# none_needed
memchecker_valgrind_happy=0  # This should suffice to get rid of the 
component
should_build=2
want_component=0
fi

We have been looking into other syntaxes to deselect the component, but did 
not find any.

Is there a better way within one plugin of a component to deselect it (or 
rather say, that none of the components should be checked for?)



> Additionally, for the platform file overriding the configure command
> line; I *think* that that's expected behavior -- the platform file is
> a tradeoff and had to be implemented as an ugly hack because of the
> way autoconf parses command line flags (IIRC, the command line flags
> are parsed and *then* the platform file is parsed -- I don't think
> there was another way to do it).  Perhaps that behavior should be
> documented.
What's the ticket#?

Sorry, if this is causing You trouble, Ralph.

CU,
Rainer

>
> On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote:
> > On 4/21/08 8:10 AM, "Jeff Squyres"  wrote:
> >> Hmm.  I do not have this problem on OS X (where I do not have
> >> Valgrind
> >> installed) as of this morning's trunk.  configure correctly
> >> determines
> >> that valgrind is not present and therefore continues on:
> >>
> >> --- MCA component memchecker:valgrind (m4 configuration macro)
> >> checking for MCA component memchecker:valgrind compile mode... static
> >> checking if MCA component memchecker:valgrind can compile... no
> >>
> >> ...etc.
> >>
> >> Note that your message indicates that configure thinks that valgrind
> >> support was explicitly requested.  In this case, configure thinks,
> >> "you explicitly requested it, I cannot provide it, so I should abort
> >> rather than give unexpected results."
> >
> > I know that - but I am not explicitly requesting it. In fact, I
> > explicitly
> > put --without-valgrind, to no effect.
> >
> > Here is what I have discovered may be the source of the problem. I had
> > inserted a enable_memchecker=yes line in my platform file. This
> > apparently
> > has the unfortunate side effect of now requiring valgrind. IMHO,
> > this should
> > not be setup that way per my earlier comment about requiring debuggers
> > unless memchecker has absolutely no other way to run - which looking
> > at the
> > framework, would not appear to be true.
> >
> > I then tried still using my platform file, but adding --disable-
> > memchecker
> > to the configure line. The disable request was apparently ignored,
> > at least
> > as far as the valgrind part of the request is concerned. The build
> > failed at
> > the same point.
> >
> > Removing the enable_memchecker=yes line from my platform file allows
> > me to
> > successfully navigate configure.
> >
> > So it appears to be a combination of memchecker=yes automatically
> > requiring
> > valgrind, and the override on the configure line of a param set by a
> > platform file not working.
> >
> > I can send you some stuff off-list in a little bit, if you still
> > need it.
> >
> >> Can you send your full configure output and config.log?
> >>
> >> On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote:
> >>> As an FYI for anyone similarly afflicted:
> >>>
> >>> The only solution I have found is to gut the file
> >>> opal/mca/memchecker/valgrind/configure.m4:
> >>>
> >>> # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not-
> >>> found])
> >>> # ---
> >>> AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[
> >>>
> >>>   happy=0  # none_needed
> >>>   happy_value=0# none_needed
> >>>   memchecker_valgrind_happy=0  # This should suffice to get rid
> >>> of the
> >>> component
> >>>   should_build=2
> >>>   want_component=0
> >>> ])dnl
> >>>
> >>> Nothing else will allow you to build unless you have the valgrind
> >>> headers
> >>> installed on your machine.
> >>>
> >>> Ralph
> >>>
> >>> On 4/21/08 7:28 AM, "Ralph H Castain"  wrote:
>  I am finding that the memchecker code is again breaking the trunk,
>  specifically on any machine that does not have valgrind installed.
>  Apparently, memchecker now forces a requirement for valgrind?
> 
>  Here is what I get:
> 
>  --- MCA component memchecker:valgrind (m4 configuration macro)
>  checking for MCA component memchecker:valgrind compile mode...
>  static
>  checking checking for the valgrind include directory ... 

Re: [OMPI devel] Memchecker: breaks trunk again

[Ralph H Castain]

Thanks Brian - I had been told precisely the opposite priority rule just a
few weeks ago by someone else, hence my confusion.


On 4/21/08 8:48 AM, "Brian W. Barrett"  wrote:

> On Mon, 21 Apr 2008, Ralph H Castain wrote:
> 
>> So it appears to be a combination of memchecker=yes automatically requiring
>> valgrind, and the override on the configure line of a param set by a
>> platform file not working.
> 
> So I can't speak to the valgrind/memchecker issue, but can to the
> platform/configure issue.  The platform file was intended to provide a
> mechanism to allow repeatability in builds.  By design, options in the
> platform file have higher priority than options given on the configure
> command line.
> 
> Brian
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Memchecker: breaks trunk again

[Jeff Squyres]

Ah, I see what's happening.

The opal/mca/memchecker/valgrind/configure.m4 file is using "want  
memchecker" to indicate that you want valgrind support.  I think that  
these should be two different issues.  I'll file a ticket.


Additionally, for the platform file overriding the configure command  
line; I *think* that that's expected behavior -- the platform file is  
a tradeoff and had to be implemented as an ugly hack because of the  
way autoconf parses command line flags (IIRC, the command line flags  
are parsed and *then* the platform file is parsed -- I don't think  
there was another way to do it).  Perhaps that behavior should be  
documented.



On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote:





On 4/21/08 8:10 AM, "Jeff Squyres"  wrote:

Hmm.  I do not have this problem on OS X (where I do not have  
Valgrind
installed) as of this morning's trunk.  configure correctly  
determines

that valgrind is not present and therefore continues on:

--- MCA component memchecker:valgrind (m4 configuration macro)
checking for MCA component memchecker:valgrind compile mode... static
checking if MCA component memchecker:valgrind can compile... no

...etc.

Note that your message indicates that configure thinks that valgrind
support was explicitly requested.  In this case, configure thinks,
"you explicitly requested it, I cannot provide it, so I should abort
rather than give unexpected results."


I know that - but I am not explicitly requesting it. In fact, I  
explicitly

put --without-valgrind, to no effect.

Here is what I have discovered may be the source of the problem. I had
inserted a enable_memchecker=yes line in my platform file. This  
apparently
has the unfortunate side effect of now requiring valgrind. IMHO,  
this should

not be setup that way per my earlier comment about requiring debuggers
unless memchecker has absolutely no other way to run - which looking  
at the

framework, would not appear to be true.

I then tried still using my platform file, but adding --disable- 
memchecker
to the configure line. The disable request was apparently ignored,  
at least
as far as the valgrind part of the request is concerned. The build  
failed at

the same point.

Removing the enable_memchecker=yes line from my platform file allows  
me to

successfully navigate configure.

So it appears to be a combination of memchecker=yes automatically  
requiring

valgrind, and the override on the configure line of a param set by a
platform file not working.

I can send you some stuff off-list in a little bit, if you still  
need it.





Can you send your full configure output and config.log?


On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote:


As an FYI for anyone similarly afflicted:

The only solution I have found is to gut the file
opal/mca/memchecker/valgrind/configure.m4:

# MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not-
found])
# ---
AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[

  happy=0  # none_needed
  happy_value=0# none_needed
  memchecker_valgrind_happy=0  # This should suffice to get rid
of the
component
  should_build=2
  want_component=0
])dnl

Nothing else will allow you to build unless you have the valgrind
headers
installed on your machine.

Ralph



On 4/21/08 7:28 AM, "Ralph H Castain"  wrote:


I am finding that the memchecker code is again breaking the trunk,
specifically on any machine that does not have valgrind installed.
Apparently, memchecker now forces a requirement for valgrind?

Here is what I get:

--- MCA component memchecker:valgrind (m4 configuration macro)
checking for MCA component memchecker:valgrind compile mode...  
static
checking checking for the valgrind include directory ... none  
needed

checking valgrind/valgrind.h usability... no
checking valgrind/valgrind.h presence... no
checking for valgrind/valgrind.h... no
configure: WARNING: *** Could not find valgrind header files, as
valgrind
support was requested
configure: error: *** Cannot continue


Could somebody please fix this? I thought we had decided many moons
ago that
we would not require specific debuggers in default build
configurations - I
am somewhat surprised, therefore, to find that memchecker is "on"  
by

default, and now requires valgrind!

I have tried --disable-memchecker, but nothing will allow me to get
past
this error.

Thanks
Ralph




___
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



--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] Memchecker: breaks trunk again

[Brian W. Barrett]

On Mon, 21 Apr 2008, Ralph H Castain wrote:


So it appears to be a combination of memchecker=yes automatically requiring
valgrind, and the override on the configure line of a param set by a
platform file not working.


So I can't speak to the valgrind/memchecker issue, but can to the 
platform/configure issue.  The platform file was intended to provide a 
mechanism to allow repeatability in builds.  By design, options in the 
platform file have higher priority than options given on the configure 
command line.


Brian

Re: [OMPI devel] Memchecker: breaks trunk again

[Ralph H Castain]

On 4/21/08 8:10 AM, "Jeff Squyres"  wrote:

> Hmm.  I do not have this problem on OS X (where I do not have Valgrind
> installed) as of this morning's trunk.  configure correctly determines
> that valgrind is not present and therefore continues on:
> 
> --- MCA component memchecker:valgrind (m4 configuration macro)
> checking for MCA component memchecker:valgrind compile mode... static
> checking if MCA component memchecker:valgrind can compile... no
> 
> ...etc.
> 
> Note that your message indicates that configure thinks that valgrind
> support was explicitly requested.  In this case, configure thinks,
> "you explicitly requested it, I cannot provide it, so I should abort
> rather than give unexpected results."

I know that - but I am not explicitly requesting it. In fact, I explicitly
put --without-valgrind, to no effect.

Here is what I have discovered may be the source of the problem. I had
inserted a enable_memchecker=yes line in my platform file. This apparently
has the unfortunate side effect of now requiring valgrind. IMHO, this should
not be setup that way per my earlier comment about requiring debuggers
unless memchecker has absolutely no other way to run - which looking at the
framework, would not appear to be true.

I then tried still using my platform file, but adding --disable-memchecker
to the configure line. The disable request was apparently ignored, at least
as far as the valgrind part of the request is concerned. The build failed at
the same point.

Removing the enable_memchecker=yes line from my platform file allows me to
successfully navigate configure.

So it appears to be a combination of memchecker=yes automatically requiring
valgrind, and the override on the configure line of a param set by a
platform file not working.

I can send you some stuff off-list in a little bit, if you still need it.


> 
> Can you send your full configure output and config.log?
> 
> 
> On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote:
> 
>> As an FYI for anyone similarly afflicted:
>> 
>> The only solution I have found is to gut the file
>> opal/mca/memchecker/valgrind/configure.m4:
>> 
>> # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not-
>> found])
>> # ---
>> AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[
>> 
>>happy=0  # none_needed
>>happy_value=0# none_needed
>>memchecker_valgrind_happy=0  # This should suffice to get rid
>> of the
>> component
>>should_build=2
>>want_component=0
>> ])dnl
>> 
>> Nothing else will allow you to build unless you have the valgrind
>> headers
>> installed on your machine.
>> 
>> Ralph
>> 
>> 
>> 
>> On 4/21/08 7:28 AM, "Ralph H Castain"  wrote:
>> 
>>> I am finding that the memchecker code is again breaking the trunk,
>>> specifically on any machine that does not have valgrind installed.
>>> Apparently, memchecker now forces a requirement for valgrind?
>>> 
>>> Here is what I get:
>>> 
>>> --- MCA component memchecker:valgrind (m4 configuration macro)
>>> checking for MCA component memchecker:valgrind compile mode... static
>>> checking checking for the valgrind include directory ... none needed
>>> checking valgrind/valgrind.h usability... no
>>> checking valgrind/valgrind.h presence... no
>>> checking for valgrind/valgrind.h... no
>>> configure: WARNING: *** Could not find valgrind header files, as
>>> valgrind
>>> support was requested
>>> configure: error: *** Cannot continue
>>> 
>>> 
>>> Could somebody please fix this? I thought we had decided many moons
>>> ago that
>>> we would not require specific debuggers in default build
>>> configurations - I
>>> am somewhat surprised, therefore, to find that memchecker is "on" by
>>> default, and now requires valgrind!
>>> 
>>> I have tried --disable-memchecker, but nothing will allow me to get
>>> past
>>> this error.
>>> 
>>> Thanks
>>> Ralph
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Memchecker: breaks trunk again

[Ralph H Castain]

As an FYI for anyone similarly afflicted:

The only solution I have found is to gut the file
opal/mca/memchecker/valgrind/configure.m4:

# MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not-found])
# ---
AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[

happy=0  # none_needed
happy_value=0# none_needed
memchecker_valgrind_happy=0  # This should suffice to get rid of the
component
should_build=2
want_component=0
])dnl

Nothing else will allow you to build unless you have the valgrind headers
installed on your machine.

Ralph



On 4/21/08 7:28 AM, "Ralph H Castain"  wrote:

> I am finding that the memchecker code is again breaking the trunk,
> specifically on any machine that does not have valgrind installed.
> Apparently, memchecker now forces a requirement for valgrind?
> 
> Here is what I get:
> 
> --- MCA component memchecker:valgrind (m4 configuration macro)
> checking for MCA component memchecker:valgrind compile mode... static
> checking checking for the valgrind include directory ... none needed
> checking valgrind/valgrind.h usability... no
> checking valgrind/valgrind.h presence... no
> checking for valgrind/valgrind.h... no
> configure: WARNING: *** Could not find valgrind header files, as valgrind
> support was requested
> configure: error: *** Cannot continue
> 
> 
> Could somebody please fix this? I thought we had decided many moons ago that
> we would not require specific debuggers in default build configurations - I
> am somewhat surprised, therefore, to find that memchecker is "on" by
> default, and now requires valgrind!
> 
> I have tried --disable-memchecker, but nothing will allow me to get past
> this error.
> 
> Thanks
> Ralph
> 
> 
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] Memchecker: breaks trunk again

[Ralph H Castain]

I am finding that the memchecker code is again breaking the trunk,
specifically on any machine that does not have valgrind installed.
Apparently, memchecker now forces a requirement for valgrind?

Here is what I get:

--- MCA component memchecker:valgrind (m4 configuration macro)
checking for MCA component memchecker:valgrind compile mode... static
checking checking for the valgrind include directory ... none needed
checking valgrind/valgrind.h usability... no
checking valgrind/valgrind.h presence... no
checking for valgrind/valgrind.h... no
configure: WARNING: *** Could not find valgrind header files, as valgrind
support was requested
configure: error: *** Cannot continue


Could somebody please fix this? I thought we had decided many moons ago that
we would not require specific debuggers in default build configurations - I
am somewhat surprised, therefore, to find that memchecker is "on" by
default, and now requires valgrind!

I have tried --disable-memchecker, but nothing will allow me to get past
this error.

Thanks
Ralph