[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)



Hm, I'm now getting errors from dpkg-shlibdeps (i.e., and installation time):
```
dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12 needed by debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11 (ELF format: 'elf64-powerpcle'; RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib')
```
See [1] for full detail. (Btw, notice the RPATH settings from openmpi.)

CMake I think installs the libraries in alphabetical order, so `libtrilinos_amesos.so.12.11` is handled before its dependency `libtrilinos_trilinosss.so.12` and cannot find the latter -- makes sense.

What's the suggested workaround here?

Cheers,
Nico

[1] https://launchpadlibrarian.net/303079195/buildlog_ubuntu-zesty-ppc64el.trilinos_12.11~20170119114916-33933755-1zesty1_BUILDING.txt.gz


On Thu, Jan 19, 2017 at 3:03 PM Nico Schlömer <nico.schloemer@gmail.com> wrote:

I can confirm that the RPATH is
```
RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib'
```
I'll just wait for the next ompi upload then.


Cheers,
Nico

On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry <mckinstry@debian.org> wrote:



On 19/01/2017 11:20, James Cowgill wrote:
> Hi,
>
> On 18/01/17 22:39, Nico Schlömer wrote:
>> I'm co-maintaining the Trilinos package [1] in Debian and recently found
>> a bunch of new lintian warnings of the kind
>> binary-or-shlib-defines-rpath [2]. It say in the description of the warning:
>> ```
>> To fix this problem, look for link lines like:
>>
>> gcc test.o -o test -Wl,--rpath,/usr/local/lib
>>
>> or
>>
>> gcc test.o -o test -R/usr/local/lib
>>
>> and remove the -Wl,--rpath or -R argument.
>> ```
>> Indeed, the Trilinos installation contains many of those lines, but they
>> are necessary too. When executing the test binaries (which are compiled
>> in the build tree alongside the libraries), they have to find the linked
>> shared libraries. Messing with the rpath is necessary.
>>
>> That's not true later on when the libraries are _installed_, of course.
>> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
>> serves exactly that purpose. For some reason, lintian doesn't seem to be
>> happy with that though.
> The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
> itself inserts. It does not affect any rpaths manually added with other
> -Wl,--rpath options. The culprit here is probably openmpi which adds all
> of these rpath entries:
>
> $ mpicc -show
> [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
> -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]
>
> Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
> it seems that most of the libraries from
> /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
> /usr/lib/x86_64-linux-gnu anyway.
>
Agreed. Will remove these on the next upload.

Best regards
Alastair

--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.


Reply to: