Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Memchecker: breaks trunk again
From: Ralph H Castain (rhc_at_[hidden])
Date: 2008-04-21 10:26:27

On 4/21/08 8:10 AM, "Jeff Squyres" <jsquyres_at_[hidden]> 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" <rhc_at_[hidden]> 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
>>> devel_at_[hidden]
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]