> I've looked for this kind of answer before - it's not as simple as it > appears. rpath arises from libraries in non-standard locations, either > alone or when linked to a binary. > > 1. Dependencies can bring in rpath: See Bug # 374797 (amd64 specific) > 2. linking binaries against pkglib_LTLIBRARY libs as opposed to > lib_LTLIBRARY libs brings in rpath because the pkglib isn't in a > standard library location. e.g. test programmes commonly need rpath > which is OK as they aren't installed but this can catch you out if an > installed binary is built in the same way. > 3. Sometimes linda reports problems with rpath when lintian does not - > this happens with one of my packages that has a GModule plugin. So are there times when this is acceptable? When I remove rpath from my binary it won't execute as it can't find the needed library. > > For that matter, it would even be nice for lintian to refer to some > > external documentation on the matter, to avoid users having to > > repeatedly filter through years of mailing list archives. > > I fear there isn't usually a one-size-fits-all answer for rpath > problems. I may be wrong. In that case it sounds like it would be helpful to have all of the current Debian knowledge on the matter aggregated in a single location. Then even if it is complex, someone encountering the warning can get a sense of different ways it is dealt with. > > So, my questions are: Have I succesfully identified the currently > > accepted ways of fixing this warning? > > Depends. Does it actually fix the warning? Yes, but it also broke my binary, which can no longer find the needed library. Any suggestions? Is rpath okay in this case? The needed library is coming from /usr/lib/courier-authlib. Charles -- My neck was sore In front before And also Sore behind Before Burma-Shave http://burma-shave.org/jingles/1937/my_neck_was
Attachment:
signature.asc
Description: Digital signature