[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
> 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



Reply to: