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" <jsquy...@cisco.com> 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" <r...@lanl.gov> 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

-- 
----------------------------------------------------------------
Dipl.-Inf. Rainer Keller   http://www.hlrs.de/people/keller
 HLRS                          Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19                  Fax: ++49 (0)711-685 6 5832
 70550 Stuttgart                    email: kel...@hlrs.de     
 Germany                             AIM/Skype:rusraink

Reply via email to