:
> 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:
>> ```
>
> > 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
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 search path so even if the
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 changed, many applications
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
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
What I meant was "one should not set rpath t
_shlibdeps when building
> packages to find on what package,version to add a dependency for a
> given objdump -p |grep -we NEEDED line.
>
> Justin
>
Do i need to provide .shlibs or shlibs.local file in debian
directory.
--
View this message in context:
http://www.nabble.com/binary-or-
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 problems for multilib.
> 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-authlib which currently uses /u
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
> courier-authlib w
> 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 out how to
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
>> > > library. Any suggestions? Is rpath okay in this case
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 allow
> > /usr/lib/$packagename wit
> 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, becau
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
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.
>
> In this case, I believe it is correct. rpath
On Wed, Jul 12, 2006 at 05:05:36PM -0400, Charles Fry wrote:
> > > 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 n
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)
> 2. linking binaries against pkglib_LTLIBR
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 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-rpath is catching all usages of the "rpath"
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" feature except
> >>one: src/Makefile.in, Line 540:
> >>
> >>
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) $(libkbibtexpart_la_OBJECTS)
> $
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 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.
It does n
On Sat, 11 May 2002 13:34:27 -0400, Matt Zimmerman <[EMAIL PROTECTED]>
wrote:
>The documentation for each tool explains the nature of its input and output,
>and how it interacts with the other tools.
That documentation expects some level of knowledge about C programming
and UNIX software developm
On Sat, May 11, 2002 at 04:37:20PM +0200, Marc Haber wrote:
> aclocal.m4, ltconfig and ltmain.sh are built by libtool? Or is that local
> stuff done by the upstream?
ltconfig and ltmain.sh are from libtool. They are used to generate the
'libtool' script actually used during the build. aclocal.
On 11 May 2002 15:30:15 +0200, Robert Bihlmeyer <[EMAIL PROTECTED]>
wrote:
>Marc Haber <[EMAIL PROTECTED]> writes:
>> >Since you're using libtool,
>>
>> Am I? Libtool is not installed in the chroot where I am building the
>> package. This suspiciously looks like somebody invented his own broken
>
Marc Haber <[EMAIL PROTECTED]> writes:
> >Since you're using libtool,
>
> Am I? Libtool is not installed in the chroot where I am building the
> package. This suspiciously looks like somebody invented his own broken
> stuff :-(
No, libtool scripts, like configure, usually come with the source.
Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> I must object to that. rpath is your friend whenever you lack write
> access to the system library directories, ie. when you're not root.
You can use LD_LIBRARY_PATH. It is much more flexible than hardcoding
paths.
> Debian packages generally
On 09 May 2002 21:41:22 +0200, Robert Bihlmeyer <[EMAIL PROTECTED]>
wrote:
>Marc Haber <[EMAIL PROTECTED]> writes:
>> W: atm-tools: binary-or-shlib-defines-rpath ./usr/sbin/mpcd
>> /home/haber/devel/linux-atm-2.4.0/debian/atm-tools/usr/lib
>
>Note that this rpath
Robert Bihlmeyer <[EMAIL PROTECTED]> writes:
> To Linux systems, generally, yes. Some commercial Unices dig rpath,
> though. Basically, if your package system sucks, rpath is your
> friend.
I must object to that. rpath is your friend whenever you lack write
access to the system library director
On Thu, May 09, 2002 at 04:04:13PM +0200, Marc Haber wrote:
> >> to do so without seriously breaking something. Could anybody more
> >> knowledgeable help me with this?
> >
> >There is a rpath-reaper packaged for Debian (I don't recall the name), it
> >will "fix" the binaries the hard way.
>
> Yo
Robert Bihlmeyer <[EMAIL PROTECTED]> writes:
> Note that this rpath, apart from being superflous, is also broken as
> it points to a directory that will be nonexistent except on your
> machine.
>
> Since you're using libtool, perhaps reading
> http://lists.debian.org/debian-devel/2002/debian-
Marc Haber <[EMAIL PROTECTED]> writes:
> W: atm-tools: binary-or-shlib-defines-rpath ./usr/sbin/mpcd
> /home/haber/devel/linux-atm-2.4.0/debian/atm-tools/usr/lib
Note that this rpath, apart from being superflous, is also broken as
it points to a directory that will be nonexistent ex
Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> If an application uses libc6 and libslang (say), it will break when
> libslang is recompiled against libc7. Therefore the libc6 version of
> libslang needs to retained in a libc6 specific directory for backwards
> compatibility, and ld.so needs t
Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> If an application uses libc6 and libslang (say), it will break when
> libslang is recompiled against libc7. Therefore the libc6 version of
> libslang needs to retained in a libc6 specific directory for backwards
> compatibility, and ld.so needs
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, Feb 18, 2002 at 01:00:44AM +0100, Kjetil Torgrim Homme wrote:
> > ldconfig generates ld.so.cache. ld.so.cache is used by ld.so to know
> > which paths should be used. Please note that this filtering mechanism
> > is crucial when RPATH isn't us
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, Feb 18, 2002 at 01:00:44AM +0100, Kjetil Torgrim Homme wrote:
> > ldconfig generates ld.so.cache. ld.so.cache is used by ld.so to know
> > which paths should be used. Please note that this filtering mechanism
> > is crucial when RPATH isn't u
On Mon, Feb 18, 2002 at 01:00:44AM +0100, Kjetil Torgrim Homme wrote:
> ldconfig generates ld.so.cache. ld.so.cache is used by ld.so to know
> which paths should be used. Please note that this filtering mechanism
> is crucial when RPATH isn't used, since there is only one ordering of
> paths for
On Mon, Feb 18, 2002 at 01:00:44AM +0100, Kjetil Torgrim Homme wrote:
> ldconfig generates ld.so.cache. ld.so.cache is used by ld.so to know
> which paths should be used. Please note that this filtering mechanism
> is crucial when RPATH isn't used, since there is only one ordering of
> paths for
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> I mean "hard path" as in an absolute location. That is the problem
> with RPATH; it puts absolute locations into the binaries. If the
> library moves, the program stops working.
>
> So if the program contained the full path to libc.so.6, we couldn't
>
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> I mean "hard path" as in an absolute location. That is the problem
> with RPATH; it puts absolute locations into the binaries. If the
> library moves, the program stops working.
>
> So if the program contained the full path to libc.so.6, we couldn't
>
On Fri, Feb 15, 2002 at 02:34:49AM +0100, Kjetil Torgrim Homme wrote:
> > If your binary contains a hard path to /lib/libc.so.6,
>
> What do you mean by a hard path? dlopen()? Sure, it won't work.
> Usually, /lib/ld-linux.so.2 is hard coded, libc is not.
I mean "hard path" as in an absolute loc
On Fri, Feb 15, 2002 at 02:34:49AM +0100, Kjetil Torgrim Homme wrote:
> > If your binary contains a hard path to /lib/libc.so.6,
>
> What do you mean by a hard path? dlopen()? Sure, it won't work.
> Usually, /lib/ld-linux.so.2 is hard coded, libc is not.
I mean "hard path" as in an absolute lo
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> > Aha, I didn't realize there was that kind of black magic in ld.so
> > (documented in ldconfig). Well, then I'd venture that ld.so is
> > imperfect. If it knows to ignore certain
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> > Aha, I didn't realize there was that kind of black magic in ld.so
> > (documented in ldconfig). Well, then I'd venture that ld.so is
> > imperfect. If it knows to ignore certai
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> David Z Maze <[EMAIL PROTECTED]> writes:
> > Yes, it should. In this case, imagine GNU libc 3 comes out, Debian
> > decides to migrate to it, and libraries linked against glibc 2 are
> > moved to /usr/i386-glibc2-linux/lib or
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> David Z Maze <[EMAIL PROTECTED]> writes:
> > Yes, it should. In this case, imagine GNU libc 3 comes out, Debian
> > decides to migrate to it, and libraries linked against glibc 2 are
> > moved to /usr/i386-glibc2-linux/lib or
| [Tollef Fog Heen]
| > chrpath isn't packaged yet, but I am sure Petter Reinholdsen
| > wouldn't object.
|
| Petter _Reinholdtsen_ do not object at all.
Sorry, my misspelling. All those ds and ts an everything. I
apologize.
| Note that chrpath isn't able to add an rpath section to an ELF fi
| [Tollef Fog Heen]
| > chrpath isn't packaged yet, but I am sure Petter Reinholdsen
| > wouldn't object.
|
| Petter _Reinholdtsen_ do not object at all.
Sorry, my misspelling. All those ds and ts an everything. I
apologize.
| Note that chrpath isn't able to add an rpath section to an ELF f
[Tollef Fog Heen]
> chrpath isn't packaged yet, but I am sure Petter Reinholdsen
> wouldn't object.
Petter _Reinholdtsen_ do not object at all. Note that chrpath isn't
able to add an rpath section to an ELF file, only modify and remove
one. (If anyone know how to add one, please send patches. :-
[Tollef Fog Heen]
> chrpath isn't packaged yet, but I am sure Petter Reinholdsen
> wouldn't object.
Petter _Reinholdtsen_ do not object at all. Note that chrpath isn't
able to add an rpath section to an ELF file, only modify and remove
one. (If anyone know how to add one, please send patches. :
* Kjetil Torgrim Homme
| Again note: This is not relevant for official Debian packages, they
| have the power to set up paths as they wish. (Aside: It would be
| mighty nice if debs supported installation in a user's home directory,
| but that would be a lot of work, and we'd need (among lots of
[EMAIL PROTECTED] writes:
> Mmm, i have two file in ocaml-base package with rpath :
>
> /usr/lib/ocaml/dllgraphics.so with RPATH=/usr/X11R6/lib
>
> and
>
> /usr/lib/ocaml/labltk/dlllabltk41.so with RPATH=/usr/lib:/usr/X11R6/lib
>
> I guess this is just the common usage of those, and not some
[EMAIL PROTECTED] writes:
> Mmm, i have two file in ocaml-base package with rpath :
>
> /usr/lib/ocaml/dllgraphics.so with RPATH=/usr/X11R6/lib
>
> and
>
> /usr/lib/ocaml/labltk/dlllabltk41.so with RPATH=/usr/lib:/usr/X11R6/lib
>
> I guess this is just the common usage of those, and not some
On Mon, Feb 11, 2002 at 02:34:02PM -0500, David Z Maze wrote:
> [EMAIL PROTECTED] writes:
> > How can i check what is contained in the rpath of a shared library
> > to make sure it is ok to override this lintian error ?
>
> objdump --private-headers will list, among, other things, the RPATH
> sett
"Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:
> On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> > To explain my outburst: Proper use of rpath is a hobby horse of mine,
> > as I've spent a lot of time with Solaris, trying to get applications
> > and libraries coming f
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> David Z Maze <[EMAIL PROTECTED]> writes:
>
> To explain my outburst: Proper use of rpath is a hobby horse of mine,
> as I've spent a lot of time with Solaris, trying to get applications
> and libraries coming from Linux to set
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> To explain my outburst: Proper use of rpath is a hobby horse of mine,
> as I've spent a lot of time with Solaris, trying to get applications
> and libraries coming from Linux to set it properly. An unpriveleged
> user can not
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> David Z Maze <[EMAIL PROTECTED]> writes:
>
> To explain my outburst: Proper use of rpath is a hobby horse of mine,
> as I've spent a lot of time with Solaris, trying to get applications
> and libraries coming from Linux to se
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> To explain my outburst: Proper use of rpath is a hobby horse of mine,
> as I've spent a lot of time with Solaris, trying to get applications
> and libraries coming from Linux to set it properly. An unpriveleged
> user can not
[EMAIL PROTECTED] writes:
> How can i check what is contained in the rpath of a shared library
> to make sure it is ok to override this lintian error ?
objdump --private-headers will list, among, other things, the RPATH
setting. (It will also show the libraries the file directly depends
on, where
On Mon, Feb 11, 2002 at 12:04:51PM -0500, David Z Maze wrote:
> Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> > Gaetano Paolone <[EMAIL PROTECTED]> writes:
> >> Lintian tells me this:
> >>
> >> W: php-gtk: binary-or-shlib-defines-rpath
> &
Hi,
On Mon, Feb 11, 2002 at 01:11:28PM -0500, Steve M. Robbins wrote:
> > rpath, and needed fixing. I vehemently oppose that. Patching libtool
> > in debian/rules is fine with me, though :-)
>
> Although the latter is a horrible kludge that is going to
> break when the internals of libtool chan
On Mon, Feb 11, 2002 at 07:01:09PM +0100, Kjetil Torgrim Homme wrote:
> David Z Maze <[EMAIL PROTECTED]> writes:
>
> > Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> > > This is a bug in lintian. It should not complain about rpath being
> > > set to directories which are part of Debian.
> >
David Z Maze <[EMAIL PROTECTED]> writes:
> Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> > This is a bug in lintian. It should not complain about rpath being
> > set to directories which are part of Debian.
>
> Yes, it should. In this case, imagine GNU libc 3 comes out, Debian
> decides to
Kjetil Torgrim Homme <[EMAIL PROTECTED]> writes:
> Gaetano Paolone <[EMAIL PROTECTED]> writes:
>> Lintian tells me this:
>>
>> W: php-gtk: binary-or-shlib-defines-rpath
>> ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
>
> This is a bug in linti
Gaetano Paolone <[EMAIL PROTECTED]> writes:
> Lintian tells me this:
>
> W: php-gtk: binary-or-shlib-defines-rpath
> ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
> N:
> N: The binary or shared library defines the `RPATH'. Usually this is a
> N: bad th
On Mon, Feb 11, 2002 at 01:04:54PM +1100, Craig Small wrote:
> > W: php-gtk: binary-or-shlib-defines-rpath
> > ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
>
>
> Strangely enough, I had this problem yesterday.
:)
> # Patch the generated libtool to avoid pas
On Mon, Feb 11, 2002 at 01:04:54PM +1100, Craig Small wrote:
> > W: php-gtk: binary-or-shlib-defines-rpath
> > ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
>
>
> Strangely enough, I had this problem yesterday.
:)
> # Patch the generated libtool to avoid pas
On Mon, Feb 11, 2002 at 12:52:49AM +0100, Gaetano Paolone wrote:
>
> Lintian tells me this:
>
> W: php-gtk: binary-or-shlib-defines-rpath
> ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
Strangely enough, I had this problem yesterday.
I was told to:
- Get new libtool
- lib
Hi,
I am packaging php-gtk.
Lintian tells me this:
W: php-gtk: binary-or-shlib-defines-rpath
./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
N:
N: The binary or shared library defines the `RPATH'. Usually this is a
N: bad thing. Most likely you will find a Makefile with a line li
On Mon, Feb 11, 2002 at 12:52:49AM +0100, Gaetano Paolone wrote:
>
> Lintian tells me this:
>
> W: php-gtk: binary-or-shlib-defines-rpath
> ./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
Strangely enough, I had this problem yesterday.
I was told to:
- Get new libtoo
Hi,
I am packaging php-gtk.
Lintian tells me this:
W: php-gtk: binary-or-shlib-defines-rpath
./usr/lib/php4/20010901/php_gtk.so /usr/X11R6/lib
N:
N: The binary or shared library defines the `RPATH'. Usually this is a
N: bad thing. Most likely you will find a Makefile with a line li
Domenico,
> > Does the shlibs.local file you posted work the way you want it to? If so,
> oh my shlibs.local works the way i want. it's ok.
> > adding the LD_LIBRARY_PATH to dpkg-shlibdeps will fix the warning message...
> > I don't know what else needs fixing?
> what i want to understand end t
On Wed, Jan 24, 2001 at 06:30:11PM -0600, Steve Langasek wrote:
> On Wed, 24 Jan 2001, Domenico Andreoli wrote:
>
> > On Wed, Jan 24, 2001 at 11:39:12AM -0600, Steve Langasek wrote:
> > > On Wed, 24 Jan 2001, Domenico Andreoli wrote:
>
> > > > uh? how is dpkg-shlibdeps related to libtool?!?
>
>
Domenico,
> > Does the shlibs.local file you posted work the way you want it to? If so,
> oh my shlibs.local works the way i want. it's ok.
> > adding the LD_LIBRARY_PATH to dpkg-shlibdeps will fix the warning message...
> > I don't know what else needs fixing?
> what i want to understand end
On Wed, Jan 24, 2001 at 06:30:11PM -0600, Steve Langasek wrote:
> On Wed, 24 Jan 2001, Domenico Andreoli wrote:
>
> > On Wed, Jan 24, 2001 at 11:39:12AM -0600, Steve Langasek wrote:
> > > On Wed, 24 Jan 2001, Domenico Andreoli wrote:
>
> > > > uh? how is dpkg-shlibdeps related to libtool?!?
>
>
Domenico,
On Wed, 24 Jan 2001, Domenico Andreoli wrote:
> my package (curl) get this warning from lintian. i tryed to gain more
> information from lintian by using -i switch but i don't get them.
> my package uses libtool and the ill-famed -rpath parameter.
> i run libtoolize -fc in order to upd
my package (curl) get this warning from lintian. i tryed to gain more
information from lintian by using -i switch but i don't get them.
my package uses libtool and the ill-famed -rpath parameter.
i run libtoolize -fc in order to update the libtool files in the build
tree but i still have the probl
Domenico,
On Wed, 24 Jan 2001, Domenico Andreoli wrote:
> my package (curl) get this warning from lintian. i tryed to gain more
> information from lintian by using -i switch but i don't get them.
> my package uses libtool and the ill-famed -rpath parameter.
> i run libtoolize -fc in order to up
my package (curl) get this warning from lintian. i tryed to gain more
information from lintian by using -i switch but i don't get them.
my package uses libtool and the ill-famed -rpath parameter.
i run libtoolize -fc in order to update the libtool files in the build
tree but i still have the prob
On 17-Jan-2001 Wesley W. Terpstra wrote:
> Hi, lintian gives me these errors:
> W: libproteus-filter1: binary-or-shlib-defines-rpath
> ./usr/lib/proteus-slave/libsfilter.ext.so.1.0.0 /usr/lib/proteus-slave
> W: libproteus-filter1: binary-or-shlib-defines-rpath
> ./
1 - 100 of 103 matches
Mail list logo
