Raphael Geissert <[EMAIL PROTECTED]> writes: > Some time ago I noticed some packages were defining a RPATH on non i386 > architectures, notably amd64. This seems to be caused by an old auto* > file, but there might be other reasons as well.
The problem is with the following code in libtool.m4: # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' /etc/ld.so.conf | tr '\n' ' '` sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra" fi (Taken from the OpenSAML package, which has "serial 47" as the version number.) ${libsuff} is defined to 64 on 64-bit Linux in the libtool logic, and therefore libtool thinks that the only normal library search paths are /lib64 and /usr/lib64. Then, when libtool is invoked to install a library in /usr/lib, it thinks that's a non-standard library and adds an rpath. Note that this problematic code is not present in the current Debian version of libtool. The equivalent part of Debian's libtool has: # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '` sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra" fi Therefore, rerunning libtoolize before compilation will fix this problem for most packages. The latest upstream libtool release also fixes this problem (with slightly different code that the current Debian package), so if upstream upgrades their version of libtool before their next release, that should also stop libtool from adding an rpath. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]