due to other reasons) -- he has two separate installs of OMPI:
/opt/ompi-1.2
/opt/ompi-1.3
Jeff, that is correct.
He builds his app with /opt/ompi-1.2/bin/mpicc.
But then he sets his LD_LIBRARY_PATH to /opt/ompi-1.3/lib/ and runs his
app with /opt/ompi-1.3/bin/mpirun. This means his app will
On Apr 28, 2009, at 7:50 AM, Ralph Castain wrote:
I'd be fascinated to understand how this works. There are multiple
function calls in MPI_Init, for example, that simply don't exist in
1.3.x. There are references to fields in structures that are no longer
present, though the structure itself doe
I'd be fascinated to understand how this works. There are multiple
function calls in MPI_Init, for example, that simply don't exist in
1.3.x. There are references to fields in structures that are no longer
present, though the structure itself does still exist. Etc.
I frankly am stunned that
Ralph, Brian, and Jeff,
Thank you for your answers.
I want to confirm Brian's words that I am "compiling the application
against one version of Open MPI, linking dynamically, then running
against another version of Open MPI".
The fact that the ABI has stabilized with the release of version 1
Remember also that the RTE API's changed between 1.2 and 1.3 - so I'm not
sure what will happen in that case. It could be that the ones touching the
MPI layer remained stable (don't honestly recall), though I believe there
are RTE calls in 1.3 that don't exist in 1.2. I would think you would have a
I'd actually be surprised if it works.
The back-end sizes of Open MPI structures definitely changed between
1.2 and 1.3. We used to think that this didn't matter, but then we
found out that we were wrong. :-) Hence, I'd think that the same
exact issues you have with taking a 1.2-compiled
I think Serge is talking about compiling the application against one
version of Open MPI, linking dynamically, then running against another
version of Open MPI. Since it's dynamically linked, the ORTE/OMPI
interactions are covered (the version of mpirun, libopen-rte, and libmpi
all match). Th
It's hard for me to believe that would work as there are fundamental
differences in the MPI-to-RTE interactions between those releases. If it
does, it could be a fluke - I personally would not trust it.
Ralph
On Mon, Apr 27, 2009 at 12:04 PM, Serge wrote:
> Hi Jeff,
>
> > That being said, we ha
Hi Jeff,
> That being said, we have fixed this issue and expect to support binary
> compatibility between Open MPI releases starting with v1.3.2 (v1.3.1
As far as I can tell from reading the release notes for v1.3.2, the
binary compatibility has not been announced yet. It was rather a bug fix
On Mar 10, 2009, at 6:53 PM, Serge wrote:
Thank you, it's very good news. If the issue has been fixed, then does
it mean that v1.3.2 will allow to run applications compiled with
v1.2.9?
Or is it starting with v1.3.2 and subsequent releases will be backward
compatible with each other?
The l
Thank you, it's very good news. If the issue has been fixed, then does
it mean that v1.3.2 will allow to run applications compiled with v1.2.9?
Or is it starting with v1.3.2 and subsequent releases will be backward
compatible with each other?
Jeff Squyres wrote:
Unfortunately, binary compatib
Unfortunately, binary compatibility between Open MPI release versions
has never been guaranteed (even between subreleases).
That being said, we have fixed this issue and expect to support binary
compatibility between Open MPI releases starting with v1.3.2 (v1.3.1
should be released soon; we
Hello,
We have a number of applications built with Open MPI 1.2 in a shared
multi-user environment. The Open MPI library upgrade has been always
transparent and painless within the v1.2 branch. Now we would like to
switch to Open MPI 1.3 as seamlessly. However, an application built with
ompi
13 matches
Mail list logo
