[Bug 1737608] Re: RPATH no longer respected for indirect dependencies

Tony Lewis tonyelewis at hotmail.com
Tue Sep 18 18:40:21 UTC 2018 

I think this is related to
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638

My understanding (gleaned in large part from comment #5 of that issue -
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638/comments/5
; errors all mine) is:

* RPATH tells the loader where to look for all libraries
* the RPATH was deprecated a long time ago because it was thought to be a mistake that RPATH is processed with higher priority than the LD_LIBRARY_PATH environment variable
* that deprecation has recently made it's way out to Ubuntu
* the ld linker (?) now defaults to setting RUNPATH instead of RPATH. RUNPATH differs from RPATH in two ways:
  * it's has *lower priority* than the LD_LIBRARY_PATH environment variable, and
  * the loader only uses it to search for direct dependencies, *not transitive dependencies*
* this means that a lot of people are going to spend a lot of time trying to figure out why their stuff is broken.

As I understand it, there are two solutions:
 * link with --disable-new-dtags to make linker revert to setting RPATH
 * fix all your .so files so that they can find their own dependencies (via a RUNPATH setting)

In my case, I fixed my problem by rebuilding my Boost libraries with a
dll-path flag to tell the build where the .so files would be installed.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1737608

Title:
  RPATH no longer respected for indirect dependencies

Status in glibc package in Ubuntu:
  Confirmed

Bug description:
  Regression from Ubuntu 16.04 to Ubuntu 17.10.

  I am building a binary with a hard-coded RUNPATH, pointing to the
  location of some vendor-supplied shared libraries.

  $ readelf -d /home/steve/src/krx/tests/krx.test | grep RUNPATH
   0x000000000000001d (RUNPATH)        Library runpath: [../library]

  On Ubuntu 16.04 the RUNPATH allowed us to locate the libraries.

  $ ldd ./krx.test
      ...
      libinisafeNet.so => ../library/libinisafeNet.so (0x00007f35c7754000)
      libiniCore.so => ../library/libiniCore.so (0x00007f35c5bea000)
      libiniPKI.so => ../library/libiniPKI.so (0x00007f35c5952000)
      libiniCrypto.so => ../library/libiniCrypto.so (0x00007f35c56e6000)

  On Ubuntu 17.10 it no longer works

  $ ldd ./krx.test
      ...
      libinisafeNet.so => ../library/libinisafeNet.so (0x00007fb4acc38000)
      libiniCore.so => not found
      libiniPKI.so => not found
      libiniCrypto.so => not found

  Note that setting LD_LIBRARY_PATH does allow the libraries to be found

  $ export LD_LIBRARY_PATH=../library
  $ ldd ./krx.test 
      ...
      libinisafeNet.so => ../library/libinisafeNet.so (0x00007fa787659000)
      libiniCore.so => ../library/libiniCore.so (0x00007fa785a86000)
      libiniPKI.so => ../library/libiniPKI.so (0x00007fa7857ee000)
      libiniCrypto.so => ../library/libiniCrypto.so (0x00007fa785582000)

  -------------------

  >> LD_DEBUG for Ubuntu 16.04 <<

  I set LD_DEBUG=all and ran ldd against my binary.

  Here is an excerpt for libiniCore.so:

   30438:     file=libiniCore.so [0];  needed by ../library/libinisafeNet.so [0]
   30438:     find library=libiniCore.so [0]; searching
   30438:      search path=../library/tls/x86_64:../library/tls:../library/x86_64:../library          (RPATH from file ./krx.test)
   30438:       trying file=../library/tls/x86_64/libiniCore.so
   30438:       trying file=../library/tls/libiniCore.so
   30438:       trying file=../library/x86_64/libiniCore.so
   30438:       trying file=../library/libiniCore.so
  The library is successfully located, and as can be seen from the search path section, it is using RPATH from file ./krx.test.

  -------------------

  >> LD_DEBUG for Ubuntu 17.10 <<

  I set LD_DEBUG=all and ran ldd against my binary.

  Here is an excerpt for libiniCore.so: (it now uses the system search
  path, not the krx.test RPATH)

   20027:     file=libiniCore.so [0];  needed by ../library/libinisafeNet.so [0]
   20027:     find library=libiniCore.so [0]; searching
   20027:      search cache=/etc/ld.so.cache
   20027:      search path=/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib            (system search path)
   20027:       trying file=/lib/x86_64-linux-gnu/tls/haswell/x86_64/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/tls/haswell/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/tls/x86_64/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/tls/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/haswell/x86_64/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/haswell/libiniCore.so
   20027:       trying file=/lib/x86_64-linux-gnu/x86_64/libiniCore.so
   ...          ...
   20027:       trying file=/lib/x86_64/libiniCore.so
   20027:       trying file=/lib/libiniCore.so
   20027:       trying file=/usr/lib/tls/haswell/x86_64/libiniCore.so
   20027:       trying file=/usr/lib/tls/haswell/libiniCore.so
   20027:       trying file=/usr/lib/tls/x86_64/libiniCore.so
   20027:       trying file=/usr/lib/tls/libiniCore.so
   20027:       trying file=/usr/lib/haswell/x86_64/libiniCore.so
   20027:       trying file=/usr/lib/haswell/libiniCore.so
   20027:       trying file=/usr/lib/x86_64/libiniCore.so
   20027:       trying file=/usr/lib/libiniCore.so

  So it seems the behaviour of ld has changed, and since it is an
  indirect dependency (krx.test --> libinisafeNet.so --> libiniCore.so)
  the RPATH for krx.test is no longer used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1737608/+subscriptions

More information about the foundations-bugs mailing list