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
1.2.8+pgi, This library was found to run an executable built with
Sorry I don't have the files you requested George.
Center for Advanced Computing
On Dec 8, 2008, at 11:31 AM, George Bosilca wrote:
> 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 that don't really match
> (hint icc and gcc).
> For Fortran there are even more issues. One was already hinted in a
> one of the answers (logical), but more are expected such as the
> representation of the "strange" type REAL16 and REAL32 (and the
> corresponding COMPLEX types). I'm sure more can be found, but these
> are enough not to support the cross-compilers stuff.
> Now, I'm really curious that this worked. Do you have access to the
> opal_config.h file for the pgi and gcc build ? Or to the config.log
> files ? If yes can you share it with us please.
> On Dec 7, 2008, at 22:06 , Brock Palen wrote:
>> 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 accidentally
>> did this and found it worked. They were all C/C++ apps (namd and
>> gromacs) but what about fortran apps? Should we expect problems
>> if someone does this?
>> I am not going to encourage this, but it is more if needed.
>> Brock Palen
>> Center for Advanced Computing
>> users mailing list
> users mailing list