"Neil L. Roeth" <[EMAIL PROTECTED]> 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. > 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. Thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers