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

Re: Failed to stop defining RPATH in libncl

+++ 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 
autotools: See https://wiki.debian.org/RpathIssue for details

(that whole page is useful - but maybe you read it and tried that stuff already?)

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: Digital signature

Reply to: