Christopher,
Building with gnu is a non-starter for us. If we ever encounter an
issue, we can't just point our users to something else as a proposed
fix. There's also technical reasons why this may not work beyond pure
C code. (Fortran and C++ both being special)
Fortran compilers from different vendors do not inter-operate with each
other, so your users must use PathScale
compilers so they can build their apps with PathScale Fortran compilers.
i could say something similar with C++ compilers, but i'd have to add
- C++ bindings were deprecated from the MPI Standard
- even if you configure Open MPI with --disable-mpi-cxx, configure will
check for a valid C++ compiler
(feel free to consider this as an Open MPI bug that will be likely
fixed in the future)
my point is that if your users do not need MPI C++ bindings, then there
is no need to worry about the C++ compiler being used
(as long as Open MPI configure is happy with it)
Boost MPI is deemed as superior to (now deprecated) MPI C++ bindings by
many C++ programmers, so this can be a good/better alternative.
imho, Open MPI is a middleware, so this is a bit different than "i
cannot build my app with compiler X",
especially since there is little or no value (from a performance point
of view) to use C compiler X versus GNU C compiler.
for example, if i were unable to build the glibc and/or the linux kernel
with compiler from vendor X, i would live happily
with using the GNU compilers for that purpose.
as an end user, i would find totally acceptable from PathScale :
- update your glibc (that won't happen, but i cannot blame PathScale for
me using an EOL distro)
- Open MPI requires a C99 compiler, so it cannot be built with PathScale
compilers. this is not a bug, this is a feature.
- build Open MPI with GNU C/C++ and Pathscale Fortran compilers (no
performance benefit can be expected
from using PathScale C/C++ compilers anyway, so mixing compilers is
perfectly acceptable)
/* of course, i would not accept this answer if i was unable to build
my optimized math libs */
on the other hand, i would find more arguable if i had to patch Open MPI.
/* my first impression is that if GNU compilers can build Open MPI,
PathScale compilers cannot because they are broken/feature incomplete,
so the compilers should be fixed, not Open MPI */
anyway, this was just how i was seeing things.
I've not tested the proposed work-around flag and not sure how
reliable it is or the impact. (I'll give it a poke and see what
happens) (Maybe this is the best solution for v2.x+)
let me clarify this, the "--disable-c99" option is just a safety net.
with the first patch you proposed, configure would not abort if the
compiler is not C99 capable.
i found that a bit dangerous, so i added this option which basically means
"i (think i) know what i am doing, so let's not abort if the compiler is
not C99 capable"
Cheers,
Gilles
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
