Hi Ralph,
1. No. Having visibility turned off without knowing it is the best way
for us to commit bugs in the trunk without noticing, I mean before
somebody else get the leg caught in the "not-compiling-trunk trap". I
had more of my share of responsibility for that kind of problems in
the past, that exactly rooted in visibility issues. I must say that it
is painful enough that some compilers will just silently ignore
visibility settings without adding the configure to the chain of guys
who just do whatever they want regardless of the requested flags. If I
can't have visibility, I want to know. Especially in debug mode.
2. If Valgrind is not available and this feature requires valgrind, it
is reasonable to disable it. Anyway, this would not lead to include
silent bugs in the trunk if it gets disabled "silently". (are you sure
though ? I used to enable this on my mac, where there is of course no
valid valgrind installed, and it compiled just fine).
Aurelien
Le 2 oct. 08 à 18:04, Ralph Castain a écrit :
Hi folks
I make heavy use of platform files to provide OMPI support for the
three NNSA labs. This means supporting multiple compilers, several
different hardware and software configs, debug vs optimized, etc.
Recently, I have encountered a problem that is making life
difficult. The problem revolves around two configure options that
apply to debug builds:
1. --enable-visibility. Frustrating as it may be, some compilers
just don't support visibility - and others only support it for
versions above a specific level. Currently, this option will abort
the configure procedure if the compiler does not support visibility.
2. --enable-memchecker. This framework has a component that requires
valgrind 3.2 or above. Unfortunately, if a valgrind meeting that
criteria is not found, this option will also abort the configure
procedure.
Is it truly -necessary- for these options to abort configure in
these conditions? Would it be acceptable for:
* visibility just to print a big warning, surrounded by asterisks,
that the selected compiler does not support visibility - but allow
the build to continue?
* memchecker to also print a big warning, surrounded by asterisks,
explaining the valgrind requirement and turn "off" the build of the
memchecker/valgrind component - but allow the build to continue? It
would seem to me that we would certainly want this for the future
anyway as additional memchecker components are supported.
If this would be acceptable, I am happy to help with or implement
the changes. It would be greatly appreciated.
Thanks
Ralph
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
