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/xfimage
/usr/bin/xfpack

But I have not all available packages installed so it is very possible that
problem is wider.

To save you time :-) - I made search with this script named "q":
ldd $1 | grep libtiff.so.3 > /dev/null && echo $1
and this command:
find /usr/bin -type f -perm /a+x -exec ./q {} ;

-----------------
Regards, Sergey



-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110226182553.12534.41167.reportbug@fc3.ru">http://lists.debian.org/20110226182553.12534.41167.reportbug@fc3.ru

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 lowering the severity and
tagging this report as unreproducible for the moment.

> 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/xfimage
> /usr/bin/xfpack

I've checked the copies of each of those binaries as shipped in squeeze
on i386, and none of them appear to be using libtiff.so. Please could
you provide the output of "ldd -v $binary" for each of the above?

Regards,

Adam




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298745818.535.6033.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1298745818.535.6033.camel@hathi.jungle.funky-badger.org

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
depends on libtiff at all; I'm therefore lowering the severity and
tagging this report as unreproducible for the moment.


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/xfimage
/usr/bin/xfpack


I've checked the copies of each of those binaries as shipped in squeeze
on i386, and none of them appear to be using libtiff.so. Please could
you provide the output of "ldd -v $binary" for each of the above?



Sid's gnuplot depends on libtiff.so.4 which while obviously not v3,
is at least a libtiff.so.


$ ldd -v /usr/bin/gnuplot | grep tiff
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007fc3655a9000)
/usr/lib/libtiff.so.4:

(I don't have xfe or multiget installed, so can't test the others.)

--
I prefer banana-flavored energy bars made from tofu.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D694F91.5070104@cox.net">http://lists.debian.org/4D694F91.5070104@cox.net

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 lowering the severity and
> > tagging this report as unreproducible for the moment.
> >
[...]
> Sid's gnuplot depends on libtiff.so.4 which while obviously not v3,
> is at least a libtiff.so.
>
> $ ldd -v /usr/bin/gnuplot | grep tiff
> libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007fc3655a9000)
> /usr/lib/libtiff.so.4:

Indeed, but ldd is recursive. gnuplot itself doesn't use libtiff,
although one of its dependencies does - specifically
libwx_gtk2u_core-2.8.so.0; see the output of "objdump
--private-headers", specifically the "NEEDED" entries.

For completeness, I've checked the i386 package providing
libwx_gtk2u_core-2.8.so.0 in squeeze, and it uses libtiff.so.4.

My suspicion is that the ldd output will be sufficient in any case, and
most likely point to a local copy of the library. If it doesn't, then
we can narrow down where the dependency is coming from.

Regards,

Adam




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298748799.535.6262.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1298748799.535.6262.camel@hathi.jungle.funky-badger.org

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110227143330.0bdf3a98.sergey_ifeo@rambler.ru">ht tp://lists.debian.org/20110227143330.0bdf3a98.sergey_ifeo@rambler.ru

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 that library shipped by the Debian wx2.8 packages is
linked about libtiff.so.4. Does moving the above out of the way resolve
your issues?

Regards,

Adam




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298818956.535.10942.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1298818956.535.10942.camel@hathi.jungle.funky-badger.org

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
libwx_gtk2u_core-2.8.so.0 => /usr/local/lib/libwx_gtk2u_core-2.8.so.0 (0xb7bad000)
libwx_baseu-2.8.so.0 => /usr/local/lib/libwx_baseu-2.8.so.0 (0xb7a60000)

Programs in /usr/local are too important for me so I can't delete them. I found the next solution:

$ export LD_LIBRARY_PATH=/lib:/usr/lib

Then gnuplot runs normally in this terminal session.

Is it normal that Debian's programs in my system gets dependencies from non-Debian libraries?
In this situation each new installation in /usr/local is a venture with unpredictable results.
Any Debian's program can stop work or can begin work in unexpected way after installation of new program in /usr/local. It makes Debian unreliable system.

-------------------
Regards, Sergey



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110227182752.0611bb4f.sergey_ifeo@rambler.ru">ht tp://lists.debian.org/20110227182752.0611bb4f.sergey_ifeo@rambler.ru

On Sun, 27 Feb 2011 15:02:36 +0000
"Adam D. Barratt" <adam@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 the problem; specifically:
>
> /usr/local/lib/libwx_gtk2u_core-2.8.so.0:
>
> The version of that library shipped by the Debian wx2.8 packages is
> linked about libtiff.so.4. Does moving the above out of the way resolve
> your issues?
>
> Regards,
>
> Adam
>

# mv /usr/local/lib/libwx_gtk2u_core-2.8.so.0 /usr/local/lib/to_del-libwx_gtk2u_core-2.8.so.0
$ gnuplot
gnuplot: error while loading shared libraries: libtiff.so.3: cannot open shared object file: No such file or directory

No, it does not work.





--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110227202050.637fec1d.sergey_ifeo@rambler.ru">ht tp://lists.debian.org/20110227202050.637fec1d.sergey_ifeo@rambler.ru

Hi.

sergey <sergey_ifeo@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 comment about its being the default libc configuration,
so not a Debian-specific issue).

> In this situation each new installation in /usr/local is a venture
> with unpredictable results.

Yes, that's why the local administrator should be very careful when
installing stuff there.

> Any Debian's program can stop work or can begin work in unexpected
> way after installation of new program in /usr/local. It makes Debian
> unreliable system.

Wrong conclusion.

Anyway, here's what you could do:
- remove that path from the linker's configuration, and set
LD_LIBRARY_PATH when running the set of binaries that need special
libraries;
- or stop installing into /usr/local, install in other directories,
and wrap your binaries to set LD_LIBRARY_PATH=/path/to/that/lib just
for those binaries;
- or even build your stuff with an RPATH pointing to the right
directory if you don't want to wrap your calls.

KiBi.

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 Debian. Non-dangerous ways are:
- not traditional;
- consumes much more time;
- more complicated.

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.

By the way: does Debian have any simple and comfortable methods of installing software
by non-privileged user only for him/herself?

---------------
WBR, Sergey



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110227225227.1ef9d276.sergey_ifeo@rambler.ru">ht tp://lists.debian.org/20110227225227.1ef9d276.sergey_ifeo@rambler.ru