Hm, I'm now getting errors from dpkg-shlibdeps (i.e., and installation
time):
```
dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12
needed by
debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11
(ELF format: 'elf64-powerpcle&
I can confirm that the RPATH is
```
RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib'
```
I'll just wait for the next ompi upload then.
Cheers,
Nico
On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry
wrote:
>
>
> On 19/01/2017 11:20, James Cowgill wrote:
On 19/01/2017 11:20, James Cowgill wrote:
> Hi,
>
> On 18/01/17 22:39, Nico Schlömer wrote:
>> I'm co-maintaining the Trilinos package [1] in Debian and recently found
>> a bunch of new lintian warnings of the kind
>> binary-or-shlib-defines-rpath [2]. It say i
On 19/01/17 12:20, Thibaut Paumard wrote:
> Le 19/01/2017 à 12:20, James Cowgill a écrit :
>> On a separate note: does this interfere with the alternatives system
>> which openmpi currently has? If an rpath is used, it will override any
>> libraries in the default linker searc
Le 19/01/2017 à 12:20, James Cowgill a écrit :
> On a separate note: does this interfere with the alternatives system
> which openmpi currently has? If an rpath is used, it will override any
> libraries in the default linker search path so even if the mpi
> alternative is c
Hi,
On 18/01/17 22:39, Nico Schlömer wrote:
> I'm co-maintaining the Trilinos package [1] in Debian and recently found
> a bunch of new lintian warnings of the kind
> binary-or-shlib-defines-rpath [2]. It say in the description of the warning:
> ```
> To fix this problem, look
Hello Nico,
>I'm co-maintaining the Trilinos package [1] in Debian and recently found a
>bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath [2].
>It say in >the description of the warning:
Usually lintian is right on such tags :p
You can look at src:
Thanks Sean for the reply.
> If so, it's probably a Lintian bug.
I thought it might be. Just filed a bug for it [1].
Cheers,
Nico
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851833
On Thu, Jan 19, 2017 at 12:50 AM Sean Whitton
wrote:
Dear Nico,
On Wed, Jan 18, 2017 at 10:39:47PM
Dear Nico,
On Wed, Jan 18, 2017 at 10:39:47PM +, Nico Schlömer wrote:
> That's not true later on when the libraries are _installed_, of course. For
> this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly
> that purpose. For some reason, lintian doesn't seem to be happy
Hi everyone,
I'm co-maintaining the Trilinos package [1] in Debian and recently found a
bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath
[2]. It say in the description of the warning:
```
To fix this problem, look for link lines like:
gcc test.o -o test -Wl,--rpath
Le 05/01/2016 16:21, Andreas Tille a écrit :
> On Mon, Jan 04, 2016 at 05:19:42PM +, Wookey wrote:
>> +++ Andreas Tille [2016-01-04 16:19 +0100]:
>>> On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
>>>>> E: ncl-tools: binary-or-shlib-defines-rpath usr
On Mon, Jan 04, 2016 at 05:19:42PM +, Wookey wrote:
> +++ Andreas Tille [2016-01-04 16:19 +0100]:
> > On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
> > > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter
> > > > /usr/lib/x86_64-linu
+++ Andreas Tille [2016-01-04 16:19 +0100]:
> On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
> > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter
> > > /usr/lib/x86_64-linux-gnu/n> > The brute force way to fix this is to use
> > >
On 04/01/16 16:32, Gianfranco Costamagna wrote:
Hi Andreas,
Hmmm, the libraries are installed in usr/lib/{triplet} so I'm not sure>what you
are talking exactly. If git.d.o would be online I'd commit
the current status with cleaned up packaging and removed RPATH.
no
Hi Andreas,
>thanks for your attempt to help.
you are welcome!
>I admit the chrpath hint by Alec Leamas was sufficient to solve the rpath
>issue.
it isn't unless you also move the libraries in usr/lib/triplet
>
>Well, I removed some cruft but I'd like to keep the
On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
> > 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 sea
tc/ld.so.conf.d/*
>
> (e.g. done by mesa libraries).
I admit the chrpath hint by Alec Leamas was sufficient to solve the rpath
issue.
> Anyhow, I fixed the packaging, and attached a patch to this email.
>
> you should be able to directly git am it.
>
> Please use some fresh p
+++ 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:
able to directly git am it.
Please use some fresh packaging for your tools, the current packaging is
somewhat bad.
If you want to fix the RPATH issue I guess you are forced to install the shared
libraries
into usr/lib or usr/lib/{triplet}, because otherwise with no RPATH, and no ld
standard path
On 04/01/16 13:45, Alec Leamas wrote:
rules:
override_dh_install:
dh_install --fail-missing
chrpath -delete debian/tmp/usr/bin/N*
Oops... That won't work. But:
rules:
override_dh_install:
chrpath -delete debian/tmp/usr/bin/N*
dh_install --fail-missing
If you al
On 04/01/16 12:45, Andreas Tille wrote:
Hm... don't know the Debian docs that well, but Fedora has some info on [2].
Basically, you should be able to add something like that in a dh_ override.
The debian GL seems to be in [3]; they look similar.
Thanks for your attempt to help but these links
On 04/01/16 11:40, Andreas Tille wrote:
Oops... by mistake, I replied to -devel. Here is the reply in correct list.
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-
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, pos
es of the lower change in my package's configure script (package
> gwyddion). This patch gets applied correctly and the lines in the
> configure script read correctly hardcode_into_libs=no.
> Still, the linker gets the --rpath /usr/lib option passed and the rpath
> gets built in... :
nfigure script
(package
gwyddion). This patch gets applied correctly and the lines in the
configure script read correctly hardcode_into_libs=no.
Still, the linker gets the --rpath /usr/lib option passed and the
rpath
gets built in... :-(
I'll investigate further, just wanted to share
ge in my package's configure script (package
gwyddion). This patch gets applied correctly and the lines in the
configure script read correctly hardcode_into_libs=no.
Still, the linker gets the --rpath /usr/lib option passed and the rpath
gets built in... :-(
I'll investigate further, just
Russ Allbery wrote:
> lintian.debian.org only checks i386.
Oh, now that makes sense!
Guess the obvious sometimes slips by unnoticed :-)
But anyway, I have an amd64 server and a package with the same problem
which chrpath solved, so my argument stands.
Cheers
--
Leo "costela" Antunes
[insert a
"Leo \"costela\" Antunes" <[EMAIL PROTECTED]> writes:
> Are you sure? Check out package 'transmission', it's been using chrpath
> for the last 3 releases (IIRC) without issues on any arch (at least
> according to lintian.debian.org).
lintian.debian.org only checks i386.
--
Russ Allbery ([EMAIL
Anibal Avelar wrote:
> I will recheck it, but I don't have an AMD machine to confirm again
> :(. I Just received this from my package's sponsor that he has a AMD
> machine.
Which of your packages has this problem? I have an amd64 machine and
could do some testing for you, if you want.
> Yes, I d
t
> will be re-generated on build-time (which is unlikely your case)
Yes, I don't want to rebuild the configure script with autoconf. I
know the aclocal.m4 would be unecessary if I rebuild the configure
script. But I don't want to do that :P
> BTW, it certainly seems easier to patch thi
al.m4 in case the configure script
will be re-generated on build-time (which is unlikely your case) or
patch the configure script directly. Or am I missing something?
BTW, it certainly seems easier to patch this option instead of patching
the '${wl}--rpath' definition, thanks for the tip!
Cheers
--
Leo "costela" Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
costela Antunes <[EMAIL PROTECTED]> wrote:
> Leo "costela" Antunes wrote:
> >
> > The way I see it the options for dealing with RPATH are:
> >
>
> - And, of course, using 'chrpath' on debian/rules
No, it doesn't work for AMD. I tried to use chrp
Leo "costela" Antunes wrote:
>
> The way I see it the options for dealing with RPATH are:
>
- And, of course, using 'chrpath' on debian/rules
Cheers
--
Leo "costela" Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
Russ Allbery wrote:
> Francesco Namuri <[EMAIL PROTECTED]> writes:
>> Il giorno 04/dic/07, alle ore 01:23, Russ Allbery ha scritto:
>
>>> The problem is that libtool doesn't think that lib64 is on the regular
>>> library search path and hence decides
des that it needs to add rpath,
which
is broken at several different levels but best avoided by just using
lib.
at this point, the only way is to patch libtool after the creation...
is it a better solution respect at the use of chrpath?
I guess what I don't understand is that I don'
Francesco Namuri <[EMAIL PROTECTED]> writes:
> Il giorno 04/dic/07, alle ore 01:23, Russ Allbery ha scritto:
>> The problem is that libtool doesn't think that lib64 is on the regular
>> library search path and hence decides that it needs to add rpath, which
>>
ely.) You could try using --libdir=/usr/lib and seeing if
that
overrides things.
tried, but this doesn't help, rpath is still set... :(
So I thought that are the problem is related to the symlink...
The problem is that libtool doesn't think that lib64 is on the regular
library search
ght that are the problem is related to the symlink...
The problem is that libtool doesn't think that lib64 is on the regular
library search path and hence decides that it needs to add rpath, which is
broken at several different levels but best avoided by just using lib.
--
Russ Allb
Hi,
Il giorno lun, 03/12/2007 alle 01.00 -0300, Felipe Sateler ha scritto:
> Leo "costela" Antunes wrote:
>
> > could implement something like the widely used
> > AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option
> > available at
that lib64/ is a symlink to lib/ ?
>
> I'm I don't think this is exactly the problem.
> RPATH is meant to help/supplant the linker on runtime, to make sure it
> finds the correct library which carries the symbols needed by the
> executable. There should be no need for it in a s
On 12/03/2007 04:38 AM, Leo "costela" Antunes wrote :
> What you could suggest upstream is that - if he really believes rpath to
> still be useful and doesn't want to completely abandon it as other gnome
> projects have done - he could implement something like the wide
Leo "costela" Antunes wrote:
> could implement something like the widely used
> AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option
> available at configure time.
Is this really needed? Most configure scripts I've dealt with support
the --di
Francesco Namuri wrote:
> I would like to know, what in your opinion is the best solution.
> And then, I am mistaken thinking that the problem is related to the fact
> that lib64/ is a symlink to lib/ ?
I'm I don't think this is exactly the problem.
RPATH is meant to help/sup
Hi,
packaging gnome-phone-manager Leo "costela" Antunes made me see that
lintian was complaining about an rpath set to /usr/lib. I've built the
package on i386 and I saw no warnings, but under an amd64 the problem is
present.
I've reported the bug to author thinking about a c
ew this message in context:
http://www.nabble.com/binary-or-shlib-defines-rpath-error-message-tf4607195.html#a13210082
Sent from the debian-mentors mailing list archive at Nabble.com.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Oct 11, 2007 at 10:35:30PM -0700, varun_shrivastava wrote:
> Justin Pryzby-43 wrote:
> > You shouldn't set rpath to /usr/lib since it's in the default search
> > path.
> >
> I haven't set the path any where in the rules file. but i am trying to
Wha
Justin Pryzby-43 wrote:
>
> Is this the same package that caused dh_strip errors?
>
No its not.
Justin Pryzby-43 wrote:
>
> You shouldn't set rpath to /usr/lib since it's in the default search
> path.
>
I haven't set the path any where in the rules file.
Romain Beauxis <[EMAIL PROTECTED]> writes:
> rpath specifies where to find the required library. Debian wants *not*
> to use it since it messes with library update: one may want to move the
> library to a new place without breaking binaries depending on it.
It also causes proble
> lintian shows
> "binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib"
> the message is same for all binaries in /usr/bin
>
> can some one please explain the reason for this message?
rpath specifies where to find the required library.
Debian wants *not* to use it since it mess
ackage that caused dh_strip errors?
> lintian shows
> "binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib"
> the message is same for all binaries in /usr/bin
You shouldn't set rpath to /usr/lib since it's in the default search
path.
> can some one please expla
hi
i am a newbee in packaging and trying out how to package some already
available source packages
i am trying to pack jpeg62_6b, the package builds successfully but running
lintian shows
"binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib"
the message is same for all binari
Charles Fry <[EMAIL PROTECTED]> writes:
>> So please, please, please do fix (remove) the rpath in the package.
>
> I would appreciate any tips on how to go about fixing this. My package
> is courierpassd, currently only available in unstable. It depends on
> courier-auth
On Fri, Jul 14, 2006 at 09:57:26AM -0400, Charles Fry wrote:
> > So please, please, please do fix (remove) the rpath in the package.
>
> I would appreciate any tips on how to go about fixing this. My package
> is courierpassd, currently only available in unstable. It depends on
&g
> So please, please, please do fix (remove) the rpath in the package.
I would appreciate any tips on how to go about fixing this. My package
is courierpassd, currently only available in unstable. It depends on
courier-authlib which currently uses /usr/lib/courier-authlib. I can't
figure
Bas Wijnen <[EMAIL PROTECTED]> writes:
> 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
>&g
On Thu, Jul 13, 2006 at 09:40:23AM -0400, Charles Fry wrote:
> > 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 all
> 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 chec
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?
Felipe Sateler <[EMAIL PROTECTED]> writes:
> Charles Fry wrote:
>> I finally found some pseudo-official documentation on this:
>>
>>http://wiki.debian.org/RpathIssue
>>
>> which confirms what you said:
>>
>>"Currently, the only valid use of this feature in Debian is to add
>>non-sta
Charles Fry wrote:
> I finally found some pseudo-official documentation on this:
>
>http://wiki.debian.org/RpathIssue
>
> which confirms what you said:
>
>"Currently, the only valid use of this feature in Debian is to add
>non-standard library path (like /usr/lib/) to libraries tha
> > So is the lintian test wrong? Should it only be checking for rpaths that
> > aren't system directories?
>
> good question!
I finally found some pseudo-official documentation on this:
http://wiki.debian.org/RpathIssue
which confirms what you said:
"Currently, the only valid use of thi
On Wed, Jul 12, 2006 at 05:32:12PM -0400, Charles Fry wrote:
> So is the lintian test wrong? Should it only be checking for rpaths that
> aren't system directories?
good question!
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
signature.asc
Description:
> > > 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.
>
>
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 t
On Wed, Jul 12, 2006 at 09:58:25PM +0100, Neil Williams wrote:
> Charles Fry wrote:
> >
> > A package I am creating from scratch is giving me the lintian warning
> > binary-or-shlib-defines-rpath.
>
> I've looked for this kind of answer before - it's not as
> 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)
>
Charles Fry wrote:
>
> A package I am creating from scratch is giving me the lintian warning
> binary-or-shlib-defines-rpath.
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
Hi,
A package I am creating from scratch is giving me the lintian warning
binary-or-shlib-defines-rpath. lintian-info in turn tells me "Please
contact debian-devel@lists.debian.org if you have questions about this."
My search revealed two possible solutions: 'configure --disab
On 2006-06-21, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> I think it is a Debian-specific issue, due to the upstream libtool maintainer
> having a disagreement with Debian about rpath. He considers it a feature
> which should always be used, we consider it a feature which may be u
Neil Williams <[EMAIL PROTECTED]> writes:
> Neil Williams wrote:
>> $ lintian pilot-qof_0.0.10-1_amd64.deb
>> W: pilot-qof: binary-or-shlib-defines-rpath ./usr/bin/pilot-qof /usr/lib64
>
> Could this be a recurrence of #268152 ?
> libffi.la: wrong libdir setting
&g
On Wed, Jun 21, 2006 at 10:37:28AM +0100, Neil Williams wrote:
> However, a recent upgrade (I suspect to libtool or gcc) on amd64 has
> meant that I now get architecture-specific lintian errors involving
> rpath :
>
> $ lintian pilot-qof_0.0.10-1_amd64.deb
> W: pilot-qof: binar
Neil Williams wrote:
> $ lintian pilot-qof_0.0.10-1_amd64.deb
> W: pilot-qof: binary-or-shlib-defines-rpath ./usr/bin/pilot-qof /usr/lib64
Could this be a recurrence of #268152 ?
libffi.la: wrong libdir setting
(originally found in libtool 1:3.4.1-7 in 2004.)
#268152 was also on amd64
amd64 has
meant that I now get architecture-specific lintian errors involving
rpath :
$ lintian pilot-qof_0.0.10-1_amd64.deb
W: pilot-qof: binary-or-shlib-defines-rpath ./usr/bin/pilot-qof /usr/lib64
$ lintian pilot-qof_0.0.10-1_i386.deb
linda also complains:
$ linda pilot-qof_0.0.10-1_amd64.deb
W
On Tue, Jan 10, 2006 at 04:08:21PM -0500, Justin Pryzby wrote:
> On Tue, Jan 10, 2006 at 10:26:56PM +0200, Simo Kauppi wrote:
> > Hi,
> >
> > While packaging swftools, I noticed that `avifile-config --libs` gives
> > -Wl,-rpath,/usr/lib -laviplay. lintian/linda obvio
On Tue, Jan 10, 2006 at 10:26:56PM +0200, Simo Kauppi wrote:
> Hi,
>
> While packaging swftools, I noticed that `avifile-config --libs` gives
> -Wl,-rpath,/usr/lib -laviplay. lintian/linda obviously are not happy
> with rpath.
It is even more annoying because /usr/lib is in the
Simo Kauppi wrote:
> While packaging swftools, I noticed that `avifile-config --libs` gives
> -Wl,-rpath,/usr/lib -laviplay. lintian/linda obviously are not happy
> with rpath.
>
> I can work around that, but I thought I ask if that should be
> considered a bug in the libavifi
Hi,
While packaging swftools, I noticed that `avifile-config --libs` gives
-Wl,-rpath,/usr/lib -laviplay. lintian/linda obviously are not happy
with rpath.
I can work around that, but I thought I ask if that should be
considered a bug in the libavifile-0.7-dev package.
And while I'm at it,
On Wed, Nov 09, 2005 at 09:21:10PM +0100, Thomas Friedrichsmeier wrote:
> > > 8. There is a rpath (as lintian told me). See the lintian warning:
> > > W: rkward:
> > > binary-or-shlib-defines-rpath ./usr/bin/rkward
> > > /usr/lib:/usr/share/qt3/lib:/usr/X11
Hi again,
on more thing:
> > 8. There is a rpath (as lintian told me). See the lintian warning:
> > W: rkward:
> > binary-or-shlib-defines-rpath ./usr/bin/rkward
> > /usr/lib:/usr/share/qt3/lib:/usr/X11R6/lib:/usr/lib/R/lib/
> >
> > I think you can directl
> Hi.
>
> this pacth can solve rpath problem.
>
> diff -u a/rules b/rules
> --- a/rules 2005-10-25 01:26:53.0 +0900
> +++ b/rules 2005-10-25 01:28:00.0 +0900
> @@ -3,9 +3,8 @@
>DEB_TAR_SRCDIR := knetdockapp-0.6
Hi.
this pacth can solve rpath problem.
diff -u a/rules b/rules
--- a/rules 2005-10-25 01:26:53.0 +0900
+++ b/rules 2005-10-25 01:28:00.0 +0900
@@ -3,9 +3,8 @@
DEB_TAR_SRCDIR := knetdockapp-0.63
DEB_AUTO_CLEANUP_RCS:= yes
Hi.
this pacth can solve rpath problem.
diff -u a/rules b/rules
--- a/rules 2005-10-25 01:26:53.0 +0900
+++ b/rules 2005-10-25 01:28:00.0 +0900
@@ -3,9 +3,8 @@
DEB_TAR_SRCDIR := knetdockapp-0.63
DEB_AUTO_CLEANUP_RCS:= yes
Jorge Salamero Sanz wrote:
> https://bencer.cauterized.net/debian/knetdockapp/
Please point to a proper Debian source package if possible.
Basically, you want other people to be able to reproduce your problem...
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE
On Mon, Oct 24, 2005 at 03:27:35PM +0200, Jorge Salamero Sanz wrote:
> hi all,
>
> i'm packaging knetdockapp, i have in de debian/rules (using cdbs):
>
> DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath --prefix=/usr
>
> but lintian says that the problem isn't
gt; lintian hint, i.e. there was an rpath option hardcoded into his
> Makefile(.am).
my Makefile.am is free of rpath options
but:
[EMAIL PROTECTED]:~/debian/knetdockapp/knetdockapp-0.63$ find . -exec grep
"rpath"
'{}' \; -print | wc -l
grep: ./debian/knetdockapp/usr/s
Hi Jorge,
for a proper answer, it would be good if you included a link to your
packages.
The last guy that had this very question was in the situation of the
lintian hint, i.e. there was an rpath option hardcoded into his
Makefile(.am).
Kind regards
T.
--
Thomas Viehmann, http
hi all,
i'm packaging knetdockapp, i have in de debian/rules (using cdbs):
DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath --prefix=/usr
but lintian says that the problem isn't solved ...
W: knetdockapp:
binary-or-shlib-defines-rpath ./usr/bin/knetdockapp
/usr/lib:/usr/share/qt3/lib:
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:
> >>
> >>>AFAICT, --disable-
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:
> >
> >
> >
> >>AFAICT, --disable-rpath is catching all usages of the "rpath" fea
Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz:
>
> 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)
ges...
> N:
> N: Processing binary package kbibtex (version 0.1.2a-2) ...
> W: kbibtex: binary-or-shlib-defines-rpath ./usr/bin/kbibtex /usr/lib
> N:
> N: The binary or shared library defines the `RPATH'. Usually this is a
> N: bad thing. Most likely you will find a Makef
On Tue, Oct 11, 2005 at 09:52:51PM +0200, Michael Hanke wrote:
> I'm packaging kbibtex which is a KDE bibtex editor. Lintian reports the
> following error for the package:
> W: kbibtex: binary-or-shlib-defines-rpath
> ./usr/lib/kde3/libkbibtexpart.so /usr/lib
That's total
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I'm packaging kbibtex which is a KDE bibtex editor. Lintian reports the
following error for the package:
N: Processing 1 packages...
N:
N: Processing binary package kbibtex (version 0.1.2a-2) ...
W: kbibtex: binary-or-shlib-defines-
On Sun, Aug 14, 2005 at 10:00:49PM +0800, Paul Wise wrote:
> Hi all,
> I'm packaging lufis[1], which will allow me to package captive ntfs, and
> I've come across an issue with lintian/linda complaining about -rpath
> Basically, lufis uses shared libraries from lufs, loca
On Sun, Aug 14, 2005 at 10:00:49PM +0800, Paul Wise wrote:
> Hi all,
>
> I'm packaging lufis[1], which will allow me to package captive ntfs, and
> I've come across an issue with lintian/linda complaining about -rpath
>
> Basically, lufis uses shared libraries from
Hi all,
I'm packaging lufis[1], which will allow me to package captive ntfs, and
I've come across an issue with lintian/linda complaining about -rpath
Basically, lufis uses shared libraries from lufs, located
in /usr/lib/lufs/ on debian (from the lufs-utils package). When I build
th
On Thu, 09 May 2002, Marc Haber wrote:
> From the docs I found, there is no legitimate reason for any package
> to define rpath on a Debian system. Is this correct? Does this also
> apply to other Linux systems?
It is correct for anything that shall end up in the usual ld.so directories
ly narrow it down by searching through the
> files they generate to find out where the rpath is coming from.
>
> libtool has been known to do this in the past (see #170350, for
> example)
This is exactly the kind of help I was looking for - thanks. You, kind
sir, are a gentleman. It
prompted me to go back and look at the last built version:
>
> [EMAIL PROTECTED]:~$ objdump -x /usr/bin/kcdlabel | grep -i rpath
> [EMAIL PROTECTED]:~$
>
> So, I didn't change anything, but suddenly I am getting an rpath built
> in. Odd. Also, notice that X is the onl
This one time, at band camp, Frank Thomas said:
> I have the same problem with my KSetiSpy package and remove rpath with
> the chrpath program.
Ah, thank you. I will look into it. Maybe there is something going on
with the KDE build
1 - 100 of 211 matches
Mail list logo
