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 run-time
That is also correct, but it does *not* work, that is why we could not
easily upgrade from v1.2 to v1.3, due to error messages like "different
size in shared object".
But the opposite works, i.e. building an app with v1.3 and running it
with v1.2. But I was concerned it was even possible. However, Brian gave
an explanation why it could work.
It also seems that while running an app, it's not even necessary to set
LD_LIBRARY_PATH, as long as I call proper mpirun (for example using an
absolute path, such as /opt/ompi-1.3/bin/mpirun). It will find its own
libraries, even if LD_LIBRARY_PATH points to a different location (v1.2)
or not set at all, as you explained, due to explicit linker dependencies.
> I'd be fascinated to understand how this works.
Ralph, I hope you see now how it can work.
= Serge
link against /opt/ompi-1.3/lib/libmpi.so. That libmpi.so has an
explicit linker dependency on the /opt/ompi-1.3/lib/libopen-rte.so,
which then depends on /opt/ompi-1.3/lib/libopen-pal.so.
Hence, he's pulling in the libopen-rte.so and libopen-pal that
correspond with the libmpi.so that he's linking against. So at least
he'll get internal consistency there.
As I mentioned before, I think it'll fail for other reasons :-), but I
*think* it should pick up a consistent set of libmpi.so, libopen-rte.so,
and libopen-pal.so...
