Re: Failed to stop defining RPATH in libncl
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
Reply to: