On Sat, 20 Dec 2003, Roger Leigh wrote: > > /usr/lib has been hard-coded into the DT_RPATH! This is because the > program was linked with the output of `cups-config --image --libs`: > > -lcupsimage -ltiff -ljpeg -lpng -lm -lz -lcups -L/usr/lib -lgnutls -lnsl
This is a classic problem with *-config scripts and why configure scripts I write intentionally ignore --libs and --cflags output from these scripts. Config scripts should never include "standard" include and lib directories, but unfortunately this happens far too often. > ^^^^^^^^^^ > On older systems which don't have '-L/usr/lib' the problem is not seen. > > $ grep CUPS_LIBS config.status > [EMAIL PROTECTED]@%-Wl,-rpath,/usr/lib -lcupsimage -ltiff -ljpeg -lpng -lm -lz > -lcups -L/usr/lib -lgnutls -lnsl%g > $ grep CUPS_LIBS src/cups/Makefile > CUPS_LIBS = -Wl,-rpath,/usr/lib -lcupsimage -ltiff -ljpeg -lpng -lm -lz -lcups > -L/usr/lib -lgnutls -lnsl > ^^^^^^^^^^^^^^^^^^^ > Here something (I assume libtool) has taken it into its head to put > /usr/lib in the RPATH. Is there any way to prevent this? This is not libtool's fault! Libtool is not responsible for the content of your Makefile so I have to presume that something else is adding the -Wl,-rpath,/usr/lib to your CUPS_LIBS variable. Regardless, this option effects the library used a run-time, not at link time. If you need to link against a library located somewhere other than /usr/lib then you should ensure that a -L option to that location is listed prior to the bogus -L/usr/lib. Also, the linker normally chooses shared libraries over static libraries, regardless of the linker search path (it scans the path twice), so it may take additional steps to ensure that the correct library is used. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
