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

Re: Lintian error binary-or-shlib-defines-rpath

On Wed, Oct 12, 2005 at 10:18:56AM +0200, Joost van Baal wrote:
> Hi,

> Op wo 12 okt 2005 om 09:32:55 +0200 schreef Michael Hanke:
>> Joost van Baal schrieb:
> >> Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz:

> >> <snip>

> >>>AFAICT, --disable-rpath is catching all usages of the "rpath" feature except
> >>>one: src/Makefile.in, Line 540:

> >>>    540         $(CXXLINK) -rpath $(kde_moduledir) $(libkbibtexpart_la_LDFLAGS) $(libkbibtexpart_la_OBJECTS) $(libkbibtexpart_la_LIBADD) $(LIBS)

> >>>Here -rpath is used unconditionally (and the target in question is
> >>>libkbibtexpart.la, so I think that is the one lintian chokes about).
> >>>I'd suggest you remove the "-rpath $(kde_moduledir)" and try again.

> >> And, of course, report this ignoring --disable-rpath as a bug to
> >> upstream.
>> Of course. I did this even before posting to this list.
>> Simply removing "-rpath $(kde_moduledir)" from the Makefile.in did not
>> make it. It led to an error about missing libkbibtexpart.lai (sorry, I
>> don't have the output here ATM).

I suspect _that_ problem occurred because it's trying to link against a
module built from the same source, which is not yet installed. So it
uses -rpath <builddir> for libtool to find the .lai, and the .lai (which
is the installed version of a .la with all paths fixed to final
destinations) tells it it's going to be in /usr/lib, so it embedds
/usr/lib into your file, but actually gives "-L $(kde_moduledir)
-lkbibtexpart -rpath $(destination_according_to_.lai_file)" or simiar to gcc.

Or at least I _think_ that's how it goes.

I'd suggest the actual problem is libtool should drop the '-rpath' part
of the gcc call when the value for -rpath is /lib, /usr/lib, or

Assuming I'm right as to the problem.

>> I don't know the autotools too well, but as Makefile.in is a generated
>> file, shouldn't the root of the error be somewhere else?

Makefile.in is only generated if using automake, in whcih case it is
as follows.

> Yes, probably in Makefile.am in the same directory.  If it's not there,
> it might be in configure.{ac,in} in the toplevel directory.

Otherwise, the .in file is not generated, but processed by configure
into a Makefile mainly by variable substitution.

You can tell an automake-generated Makefile.in because it'll make you
cry like a small child if you accidentally view it in a text editor.

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/

Attachment: pgpwFJHsuQVpS.pgp
Description: PGP signature

Reply to: