Francesco Namuri wrote: > I would like to know, what in your opinion is the best solution. > And then, I am mistaken thinking that the problem is related to the fact > that lib64/ is a symlink to lib/ ? I'm I don't think this is exactly the problem. RPATH is meant to help/supplant the linker on runtime, to make sure it finds the correct library which carries the symbols needed by the executable. There should be no need for it in a system where the linker is correctly configured and all installed libraries are in predictable places, such as Debian, but in a system where libraries could possibly be installed in different places, this becomes useful. With that in mind, what I interpret from the given reason is that libtool could be trying to deal with a possibly mixed 32/64 installation, where it wouldn't trust the linker to find the correct library. This isn't needed for Debian. At any rate, this is just speculation. What you could suggest upstream is that - if he really believes rpath to still be useful and doesn't want to completely abandon it as other gnome projects have done - he could implement something like the widely used AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option available at configure time. This in turn could be added to debian/rules and the chrpath hack could be removed. Hope it helps. Also, something I hadn't seen while sponsoring the package: it seems that you accidentally copied the rules file to a file named '\' on the base source code dir. Cheers -- Leo "costela" Antunes [insert a witty retort here]
Attachment:
signature.asc
Description: OpenPGP digital signature