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
/usr/local/lib.
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)
[EMAIL PROTECTED]
"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/
-----------------------------------------------------------
pgpWGCT73h8nd.pgp
Description: PGP signature
