On Mon, Jan 04, 2016 at 03:07:40PM +0000, Wookey wrote: > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter > > /usr/lib/x86_64-linux-gnu/ncl > > N: > > N: The binary or shared library sets RPATH. This overrides the normal > > N: library search path, possibly interfering with local policy and > > causing > > N: problems for multilib, among other issues. > > N: > > N: The only time a binary or shared library in a Debian package should > > set > > N: RPATH is if it is linked to private shared libraries in the same > > N: package. In that case, place those private shared libraries in > > N: /usr/lib/<package>. Libraries used by binaries in other packages > > should > > N: be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in > > N: which case RPATH is unnecessary. > > If this is just a library then it should be in > > /usr/lib/<triplet>. Only plugins that are used internally and never > externally should be in /usr/lib/<triplet>/<package>. And because this > is not on the normal search path an rpath may be needed to load > them. In this case the above lintian warning is not an error.
This .../<package> path is simply wrong and the libraries are not installed to this place in the package. > The brute force way to fix this is to use chrpath to remove the rpath > from the binary at the end of the build. This is what I have now. > Better is to stop it being generated with > CMAKE: SKIP_BUILD_RPATH TRUE > autotools: See https://wiki.debian.org/RpathIssue for details > > (that whole page is useful - but maybe you read it and tried that stuff > already?) Yes. This is what I've tried but failed and was thus writing here. In short: Brute force chrpath does the trick on my local Git repository. Thanks anyway Andreas. -- http://fam-tille.de
