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

Re: binary-or-shlib-defines-rpath documentation

On Wed, Jul 12, 2006 at 05:32:12PM -0400, Charles Fry wrote:
> > > > 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.
> > 
> > In this case, I believe it is correct. rpath is bad when it points to
> > a system dir such as /usr/lib. Is good when it points to an
> > application private dir.
> So is the lintian test wrong? Should it only be checking for rpaths that
> aren't system directories?

No, the lintian test is not wrong.  However, an override is in order in this
situation, IMO.

In almost any situation rpath is a bad thing.  It is a very good idea to let
lintian check this.  A "private" library for the package is an exception.  Of
course lintian could also check and allow /usr/lib/$packagename without a
warning.  However, the rpath check is useful in general, because most packages
don't need rpaths to run (their libraries are in the system library path) and
shouldn't have them.

About LD_LIBRARY_PATH, apart from it breaking all kinds of things, it is IMO
also "owned" by the user, which means that, except in special situations,
programs must not touch it.  The user may want to set it to a specific value
for her own reasons, and if at all possible that should result in what the
user expects.  If the program changes the value, the user will not understand
why things don't work.

And thanks for the chrpath hint!  That's exactly what I was looking for to get
rid of my rpaths during cross-compilation.  (I didn't test if it works yet,
but I suppose it will.)  I think running sed on Makefiles is just too big a
hack, even if it is easy.


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

Reply to: