This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
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
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.