IANAE, but I just went through a package cleaning up the library and rpath
handling, so perhaps I can offer some help.
I would start by cleansing your makefiles of any explicit mention of /usr/lib,
/lib, and any other directories listed in ld.so.conf (e.g., /usr/X11R6/lib).
These are part of the default path searched by ld.so, so it is unnecessary to
explicitly include them with -L or -rpath options. Upstream's makefiles might
include them as "-L$(libdir)" or "-rpath $(libdir)", because they have to work
when libdir is /usr/local/lib, or /home/joeuser/gimp-print/lib, or whatever
results from specifying the --prefix option to configure. You don't, because
the libraries on a Debian system are required by policy to be in /usr/lib
(except in some special cases, in which case IIRC the consensus is that you
just ignore the lintian warning). My package now compiles and links with no
explicit mention whatsoever of -L/usr/lib, though it has several -l options
for libraries that are in /usr/lib.
My guess is that the explicit presence of /usr/lib somewhere in your makefiles
(Makefile.am, configure.in, etc.) is fooling automake and/or libtool into
thinking it needs to add /usr/lib to rpath. The docs for those tools say they
will add -rpath automatically, though it's not clear in what cases they will
do this. Make sure you are finding all the libraries you need through the
proper autoconf macros (e.g., AC_CHECK_LIB) and look carefully at the
configure output to see whether it found them or not.
If that does not help, or you are willing to live with a crude hack, you can
do the following in debian/rules:
build-stamp:
dh_testdir
./configure --prefix=/usr
# Patch the generated libtool to avoid passing -rpath when linking,
# and to explicitly link libraries against the libraries they
# depend on.
sed < libtool > libtool-2 \
-e 's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec="
-D__LIBTOOL_IS_A_FOOL__ "/' -e '/^archive_cmds="/s/"$$/ \\$$deplibs"/'
mv libtool-2 libtool
chmod 755 libtool
make
touch build-stamp
I used to do this (after asking the same question on the same mailing list
over a year ago) until I did as I described above. Then I removed this hack
from debian/rules. One advantage of the above hack, though, is that it avoids
changing the upstream's autoconf/automake input files, which requires you to
regenerate the various makefiles and caused me some timestamp problems, as
described in the docs for the autotools-dev package.
On Apr 23, Roger Leigh ([EMAIL PROTECTED]) wrote:
> I'm getting this warning from lintian:
>
> $ lintian -i gimp-print_4.2.5-3_i386.changes
> W: cupsys-driver-gimpprint: binary-or-shlib-defines-rpath
> ./usr/lib/cups/backend/epson /usr/lib
> N:
> N: The binary or shared library defines the `RPATH'. Usually this is a
> N: bad thing. Most likely you will find a Makefile with a line like:
> N: gcc test.o -o test -Wl,--rpath
> N: or
> N: gcc test.o -o test -R/usr/local/lib
> N: Please contact debian-devel@lists.debian.org if you have questions
> N: about this.
> N:
> W: cupsys-driver-gimpprint: binary-or-shlib-defines-rpath
> ./usr/lib/cups/backend/canon /usr/lib
> W: cupsys-driver-gimpprint: binary-or-shlib-defines-rpath
> ./usr/lib/cups/filter/rastertoprinter /usr/lib
> W: cupsys-driver-gimpprint: binary-or-shlib-defines-rpath
> ./usr/lib/cups/filter/commandtoepson /usr/lib
>
> Looking at the build log, rpath /is/ being used, firstly when linking
> libgimpprint:
>
> /bin/sh ../../libtool --mode=link gcc -Wall -Wcast-align
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wnested-externs -Wwrite-strings -pedantic -g -O2 -o libgimpprint.la
> -version-info 2:0:1 -rpath /usr/lib print-lexmark.lo print-canon.lo
> print-dither.lo print-escp2.lo print-escp2-data.lo print-pcl.lo
> print-ps.lo print-util.lo print-color.lo print-weave.lo
> print-version.lo print-dither-matrices.lo -lm -lz
>
> However, this a libtool option, and does not actually result in
> DT_RPATH being set in the shared library. When building all the cups
> binaries, ld rpath is used, but is not mentioned in the
> Makefile/Makefile.am:
>
> /bin/sh ../../libtool --mode=link gcc -Wall -Wcast-align
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wnested-externs -Wwrite-strings -pedantic -g -O2 -o epson epson.o
> ../../lib/libprintut.la -Wl,-rpath,/usr/lib -lcupsimage -ltiff -ljpeg
> -lpng -lm -lz -lcups -L/usr/lib -lgnutls -lnsl -lz
>
> gcc -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wnested-externs -Wwrite-strings -pedantic -g
> -O2 -o epson epson.o -Wl,-rpath -Wl,/usr/lib
> ../../lib/.libs/libprintut.al -lcupsimage -ltiff /usr/lib/libjpeg.so
> -lpng -lm -lcups -L/usr/lib /usr/lib/libgnutls.so /usr/lib/libtasn1.so
> /usr/lib/libgcrypt.so -lnsl -lz
>
> What is making libtool use ld's -rpath option here? Is it something
> to do with the libraries being linked, which are different between the
> libtool and gcc commands? Why are libjpeg/libgnutls etc. absolute
> paths, and why are the libgnutls dependencies expanded by libtool?
>
>
> Thanks,
> Roger
>
> --
> Roger Leigh
>
> Printing on GNU/Linux? http://gimp-print.sourceforge.net/
> GPG Public Key: 0x25BFB848 available on public keyservers
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Neil Roeth
