]] 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 user
> 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_P
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
Olaf van der Spek writes:
> On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
> 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 goo
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
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 and lib in
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 desig
On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson 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 (that's what D
[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
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
Hi.
sergey (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 comment about its bei
On Sun, 27 Feb 2011 15:02:36 +
"Adam D. Barratt" 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 the problem; spe
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
l
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 th
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-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
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 therefo
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 question
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 lowerin
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
/usr/bin/xfi
18 matches
Mail list logo
