On Wed, 02 Mar 2011, Tollef Fog Heen wrote:
]] Henrique de Moraes Holschuh
| Actually, we usually use it to *remove* bogus rpath, but hey, it would
| be a poor tool if it couldn't be used to add a proper rpath :)
It doesn't know how to add an rpath, just change or remove one. Patches
]] Henrique de Moraes Holschuh
| Actually, we usually use it to *remove* bogus rpath, but hey, it would
| be a poor tool if it couldn't be used to add a proper rpath :)
It doesn't know how to add an rpath, just change or remove one. Patches
gladly accepted. :-)
--
Tollef Fog Heen
UNIX is
Hi,
On 28/02/2011 02:01, Andreas Rottmann wrote:
Most software allows this without issues -- just run ./configure
--prefix=$HOME. You need to adjust $PATH and $LD_LIBRARY_PATH inside
your shell startup scripts, and you're done.
I'd however strongly suggest not adding any additional
Most software allows this without issues -- just run ./configure
--prefix=$HOME. You need to adjust $PATH and $LD_LIBRARY_PATH inside
your shell startup scripts, and you're done.
This will not work. Let's imagine that user have installed some program A
in $HOME. Then user set $LD_LIBRARY_PATH
Is it possible that this problem exists because I have some old programs in
/usr/local that I moved from my previous Slackware system?
I have no gnuplot in /usr/local/bin.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
Is it possible that this problem exists because I have some old
programs in /usr/local that I moved from my previous Slackware system?
Yes, I suspect that's the problem; specifically:
/usr/local/lib/libwx_gtk2u_core-2.8.so.0:
The version of
I also reported this problem to gnuplot's maintainers as bug #615289 before I
found how many programs is depend on libtiff.so.3 on my system.
With Julien's help I have discovered that gnuplot gets dependencies from old
libraries in /usr/local:
$ ldd /usr/bin/gnuplot | grep /usr/local
On Sun, 27 Feb 2011 15:02:36 +
Adam D. Barratt a...@adam-barratt.org.uk wrote:
On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
Is it possible that this problem exists because I have some old
programs in /usr/local that I moved from my previous Slackware system?
Yes, I suspect that's
Hi.
sergey sergey_i...@rambler.ru (27/02/2011):
Is it normal that Debian's programs in my system gets dependencies
from non-Debian libraries?
Phrased otherwise, it's normal to get to look into /usr/local/lib
since that's the linker's configuration, see /etc/ld.so.conf.d/libc.conf
(which has a
Thank you for detailed explanation.
Please note that most software that is not included in Debian are distributed
in source tarballs. Most of this software installs to /usr/local by default now.
(You type configure make make install - and program installed)
So, default way is dangerous way in
[sergey]
It is a good reason to think about Debian's (or GNU/Linux) usability and
ways to increase it.
It all was about installing software system-wide by administrator.
Well, putting /usr/local/lib in the default library search path, and
upstream software using /usr/local/lib by default,
On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson pe...@p12n.org wrote:
Unfortunately (from your perspective) there is not a way to configure a
default library search path differently for binaries in different
places. So if you want /usr/local/bin binaries to see /usr/local/lib
by default
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
places. So if you want /usr/local/bin binaries to see /usr/local/lib
by default (that's what Debian and other Linux systems do, on purpose),
then all your system binaries will see them too. Anyway, it's not a
bug or even really a design flaw
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
But there is an ordering choice. local has priority.
By default, we assume the local administrator knows what he is doing.
That is not going to change.
Sure. But Sergey has a good point: why are there no bin
Olaf van der Spek olafvds...@gmail.com writes:
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
But there is an ordering choice. local has priority.
By default, we assume the local administrator knows what he is doing.
That is not going to change.
Sure.
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
Sure. But Sergey has a good point: why are there no bin and lib inside
/home so normal users can safely install software without risking
AFAIK, there are strong security concerns. You cannot have unprotected
directories in the default linker paths.
Package: general
Severity: grave
Justification: renders package unusable
Some programs can not start because of missing libtiff.so.3 file.
I found libtiff.so.3 dependencies in this files on my system:
/usr/bin/gnuplot
/usr/bin/xfe
/usr/bin/xfview
/usr/bin/xfwrite
/usr/bin/multiget
Processing commands for cont...@bugs.debian.org:
severity 615476 important
Bug #615476 [general] general: many binaries are linked with non-existent
libtiff.so.3 library
Severity set to 'important' from 'grave'
tag 615476 + unreproducible
Bug #615476 [general] general: many binaries are
severity 615476 important
tag 615476 + unreproducible
thanks
On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
Some programs can not start because of missing libtiff.so.3 file.
I suspect this is a local problem, as none of the packages in question
depends on libtiff at all; I'm therefore
On 02/26/2011 12:43 PM, Adam D. Barratt wrote:
severity 615476 important
tag 615476 + unreproducible
thanks
On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
Some programs can not start because of missing libtiff.so.3 file.
I suspect this is a local problem, as none of the packages in
On Sat, 2011-02-26 at 13:08 -0600, Ron Johnson wrote:
On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
Some programs can not start because of missing libtiff.so.3 file.
I suspect this is a local problem, as none of the packages in question
depends on libtiff at all; I'm therefore
21 matches
Mail list logo
