Could libtiff.so.3 be provided as a symlink to libtiff.so.4?

Reported by Denis Silakov on 2009-10-20
This bug affects 8 people
Affects Status Importance Assigned to Milestone
tiff (Ubuntu)

Bug Description

Currently Ubuntu uses libtiff.so.4 and libtiffxx.so.0 sonames for libtiff libraries, while upstream (and some other distributions) uses libtiff.so.3 and libtiffxx.so.3.

I guess here is the reason of why these sonames in Debian, Ubuntu & co differ from the ones in upstream:

i.e. initially Debian guys decided to separate sonames of libtiff and libtifxx, and increased the number in libtiff soname. So libtiff.so.3 in upstream corresponds to libtiff.so.4 in Debian/Ubuntu/....

That is, from the functionality point of view, upstream's libtiff.so.3 and Ubuntu's libtiff.so.4 are the same libraries and there are no ABI differences between them that would make soname change reasonable.

However, the problem is that applications have to depend either on libtiff.so.3 or on libtiff.so.4. Looking for libtiff.so.3 problems in Ubuntu forums gives some results with problematic programs that cannot be launched 'as is' (in binary form, without recompilation). The common solution for such problems is to manually create libtiff.so.3 symlink to libtiff.so.4.

I wonder, is it possible to provide these links in the tiff package by default:
libtiff.so.3 -> libtiff.so.4
libtiffxx.so.3 -> libtiffxx.so.0

This would really help to create portable applications that can be launched in different distributions without recompilation (or forcing users to manually create symlinks).

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in tiff (Ubuntu):
status: New → Confirmed
phil (fongpwf) wrote :

It seems that the Samsung unified print driver is one of the applications that look for libtiff.so.3.

Geir Ove Myhr (gomyhr) wrote :

The reason that the soname is different in Debian and upstream is explained in /usr/share/doc/libtiff4/README.Debian:

This version of libtiff is installed with a different shared library
soname from the upstream version. This is because an accidental
change to the library's ABI was introduced somewhere between 3.5.7 and
3.6.1. There are no source-level incompatibilities between 3.5.7 and
the current version, so any application that worked with 3.5.7 should
work fine when recompiled with the libtiff4 packages.

Changed in tiff (Ubuntu):
status: Confirmed → Won't Fix
jlp (jan-l-peterson) wrote :

So, changed to "won't fix" why, exactly? This problem just bit me with some third party software that was developed for Red Hat (but I want to run it on Ubuntu).

Jose Gómez (adler-dreamcoder) wrote :

I just had the same problem trying to run an application using OpenCV.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers