FWIW, the README describes some of the Fortran issues:
- Open MPI will build bindings suitable for all common forms of
Fortran 77 compiler symbol mangling on platforms that support it
(e.g., Linux). On platforms that do not support weak symbols (e.g.,
OS X), Open MPI will build Fortran 77
Looks like the same source tree was used cleaned (distclean). So I
don't have config logs for gcc or pgi.. Also I can't find
opal_confg.h in ether the configured/built source or installed
location,
1.2.8+pgi, This library was found to run an executable built with
1.2.6+gcc
Sorry I
Black magic happens all the time. To keep it simple, we do not expect
different compilers to be 100% compatible, so this is completely
unsupported by the Open MPI community. Moreover, we already know some
compilers that claim gcc compatibility, when there are always some
[obscure] things th
I seem to remember Fortran logicals being represented differently in
PGI to other Fortran (1 vs -1 maybe - cant remember). Causes
grief with things like MPI_Test.
David
Brock Palen wrote:
I did something today that I was happy worked, but I want to know if
anyone has had problem with it.
A
Many of today's compilers for Linux (pgi, intel, etc.) are designed to
be link-compatible with gcc. That must extend to calling conventions
(mangling schemes and argument passing, etc.)
If it's static link-compatible, surely this applies to dynamic (runtime)
linking (right?)
Is there stuff going
I did something today that I was happy worked, but I want to know if
anyone has had problem with it.
At runtime. (not compiling) would a OpenMPI built with pgi work to
run a code that was compiled with the same version but gcc built
OpenMPI ? I tested a few apps today after I accidental
