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" <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
--
Jeff Squyres
Cisco Systems
