http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367115#10 /usr/$arch/lib is already set in sys_lib_search_path_spec via the cross-compiler and --print-search-dirs, however, rpath persists. After a little investigation with the Emdebian Crush builds, I got this summary of the problems: http://wiki.debian.org/EmdebianAuditRpath I've only tested changes in a few packages but one thing that is promising is adding the /usr/$arch/lib path to sys_lib_dlsearch_path_spec as well as the existing setting in sys_lib_search_path_spec causes libtool (and therefore make) to omit any call to rpath when relinking the binary at the build stage. Doing this via the cross-compiler will allow more arbitrary rpaths to be allowed for useful purposes in upstream development. Are there likely side-effects from this change? The difference is that sys_lib_search_path_spec has abspath support to handle the long-winded way that arm-linux-gnueabi-gcc outputs the search directories: libraries: =/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/ That last one resolves to the /usr/$arch/lib/ $ realpath /usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/lib/ /usr/arm-linux-gnueabi/lib For dlsearch to gain the same listing, it will also need abspath support. The problems appear to show up in packages that build against libraries other than plain libc6 - simple packages that have no other build-dependencies only show an rpath to /usr/lib in the build log which libtool then removes. I think we need the same behaviour for /usr/$arch/lib. (Note, this does need to come from --print-search-dirs output of the cross-compiler as these paths are not fixed and may change in future.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpmwm2tmNiGT.pgp
Description: PGP signature