On Tue, Apr 25, 2006 at 08:06:05PM -0700, Russ Allbery wrote: > Tyler MacDonald <[EMAIL PROTECTED]> writes: > > Russ Allbery <[EMAIL PROTECTED]> wrote: > > >> > W: libapache2-mod-bt: binary-or-shlib-defines-rpath > >> > ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib > > >> It's not clear where this is coming from, as the Debian apxs2 should > >> not be doing this. But I haven't looked at your package rules to see > >> how you're building the shared library. > > > Debian's apxs2 clearly states: > > > /usr/bin/apxs2 +447: $opt .= " -rpath $CFG_LIBEXECDIR -module > > -avoid-version $apr_ldflags"; > > -rpath as an option to libtool is separate and not equivalent to rpath in > a shared library build. -rpath sometimes results in an rpath in the > resulting object, but generally does not. > > However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's > probably a problem. In general, the string "/usr/local" should not appear > anywhere in your build for Debian packages. I have often wondered if it would be useful to have a check (say, in lintian ...) grepping the binary package contents for the build directory ... assuming that the build directory is a sufficiently long string, perhaps larger binary packages will need longer build paths, but this doesn't seem like a real problem; /buildd/ itself is long enough to make a random occurance in an enourmous package beyond unlikely.
I suspect the only think preventing this from being implemented is that too many things would be affected .. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
