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 wrote
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 libtool,
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 th
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
