FYI,
debian libtool packages take care of this with this patch:
https://git.launchpad.net/ubuntu/+source/libtool/tree/debian/patches/link_all_deplibs.patch
Best,
Bert
On Mon, Nov 19, 2018 at 12:01 AM Christopher Samuel wrote:
>
> Hi Brian,
>
> On 17/11/18 5:13 am, Barrett, Brian via devel
Hi Brian,
On 17/11/18 5:13 am, Barrett, Brian via devel wrote:
> Unfortunately, I don’t have a good idea of what to do now. We already
> did the damage on the 3.x series. Our backwards compatibility testing
> (as lame as it is) just links libmpi, so it’s all good. But if anyone
> uses
Gilles -
Look at the output of Chris’s libtool link line; you can see it’s explicitly
adding a dependency on libopen-pal.so to the test binary. Once it does that,
it’s game over, the OS linking system will, rightly, complain about us changing
the c:r:a in the libtool version system in a way
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
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
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
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
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
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
