Re: lintian rpath warning
On Apr 25, Roger Leigh (roger@whinlatter.uklinux.net) wrote:
> "Neil L. Roeth" <neil@occamsrazor.net> writes:
>
> > IANAE, but I just went through a package cleaning up the library and rpath
> > handling, so perhaps I can offer some help.
>
> Thanks!
>
> > 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.
>
> None of this stuff happens. I wrote the Makefile.ams myself, and
> there are no hard-coded paths, -rpath or -L options at all.
>
> > 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.
>
> [libtool]
> > 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.
>
> This is coming from
>
> $ cups-config --libs
> -lcups -L/usr/lib -lgnutls -lnsl
>
> $ cups-config --image --libs
> -lcupsimage -ltiff -ljpeg -lpng -lm -lz -lcups -L/usr/lib -lgnutls -lnsl
>
> Quite why the -L/usr/lib is in the middle like that, I'm not sure. Is
> this a problem with cups-config, or libtool? If this is the root
> cause, there's little I can do myself to fix things.
Seems worth exploring. I am not familiar with cups; how is this command line
contructed, and how does the output feed into the make process?
> > If that does not help, or you are willing to live with a crude hack, you can
> > do the following in debian/rules:
> >
> > 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
> >
> > 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.
>
> That's handy, but it's not a very big issue (I wrote most of the build
> stuff myself). I am reluctant to do this, because it's a bit ugly.
> I'll see if libtool 1.5 (just out) improves things, and go from there.
It is ugly, which was part of the motivation for me to get rid of it.
However, the flip side is the possibly tedious and long effort to get rid of
the rpath by tracking it down through the whole build process.
The documentation for the automake/autoconf/libtool tools is fairly extensive,
and there is a package (autobook) for the tutorial book, too. I found it all
helpful while working on my package.
--
Neil L. Roeth
Reply to: