This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
> due to other reasons) -- he has two separate installs of OMPI:
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.
> 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...