Chris,
I am a bit puzzled at your logs.
As far as I understand,
ldd libhhgttg.so.1
reports that libopen-rte.so.40 and libopen-pal.so.40 are both
dependencies, but that does not say anything on
who is depending on them. They could be directly needed by
libhhgttg.so.1 (I hope / do not think it is
On 15/11/18 12:10 pm, Christopher Samuel wrote:
> I wonder if it's because they use libtool instead?
Yup, it's libtool - using it compile my toy example shows the same
behaviour with "readelf -d" pulling in the private libraries directly. :-(
[csamuel@farnarkle2 libtool]$ cat hhgttg.c
int answer
On 15/11/18 11:45 am, Christopher Samuel wrote:
> Unfortunately that's not the case, just creating a shared library
> that only links in libmpi.so will create dependencies on the private
> libraries too in the final shared library. :-(
Hmm, I might be misinterpreting the output of "ldd", it looks
On 15/11/18 2:16 am, Barrett, Brian via devel wrote:
> In practice, this should not be a problem. The wrapper compilers (and
> our instructions for linking when not using the wrapper compilers)
> only link against libmpi.so (or a set of libraries if using Fortran),
> as libmpi.so contains the pub
Chris -
When we look at ABI stability for Open MPI releases, we look only at the MPI
and SHMEM interfaces, not the internal interfaces used by Open MPI internally.
libopen-pal.so is an internal library, and we do not guarantee ABI stability
across minor releases. In 3.0.3, there was a backwar
Hi folks,
Just resub'd after a long time to ask a question about binary/backwards
compatibility.
We got bitten when upgrading from 3.0.0 to 3.0.3 which we assumed would be
binary compatible and so (after some testing to confirm it was) replaced our
existing 3.0.0 install with the 3.0.3 one (be
