+++ Andreas Tille [2016-01-04 11:40 +0100]: > Hi, > > I'm trying to package libncl[1] but I failed to fight the following > lintian error: > > > 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. So you probably want to move the library to /usr/lib/<triplet>. But if it's internal then leaving it in /usr/lib/<triplet>/<package> and letting it have an rpath is fine. The brute force way to fix this is to use chrpath to remove the rpath from the binary at the end of the build. 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?) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature