[Development] RPATH in libraries

[Thiago Macieira]

On terça-feira, 6 de agosto de 2013 23:22:10, Konrad Rosenbaum wrote:
> Ok, I found the answer to my own question: DT_RUNPATH is radically different
> from DT_RPATH - if it was only evaluated after $LD_LIBRARY_PATH it would
> not be a problem, but it also does not apply to libraries loaded by the
> libraries I found in this RUNPATH. So if I open a plugin that does not have
> RUNPATH set, but requires Qt it will attempt to load Qt not from my
> RUNPATH, but from the system directories. This will likely crash my
> application.

Which, in my opinion, is the right thing to do. Each ELF module has 
information to find the libraries that it needs. One module should not influence 
the searching of another: if they were correctly installed and work under 
other situations, they should work now too.

The ELF standard does not take into account our situation: private API being 
shared between libraries. Just think of the fact that we require users to ship 
libQtDBus.so.4 on Linux, even if their applications don't use D-Bus. (Exercise 
left to the reader)

> > The question is: why does your system linker not enable the new dtags from
> > 10-15 years ago?
> 
> That would be a question for the Debian maintainers. Or probably the
> binutils maintainers (Debian seems to tend to stay with upstream in this
> case, I didn't check very thoroughly though).

That's a good question. I never got an answer from the binutils people. From 
Debian, I wouldn't know, I only send the request to change to distributions 
I've used.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130806/91a6152b/attachment.sig>