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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
