Re: libtiff borken - cannot build anymore?
Russ Allbery <rra@debian.org> wrote:
> Jay Berkenbilt <qjb@debian.org> writes:
>> Ondřej Surý <ondrej@sury.org> wrote:
>
>>> This results in:
>>>
>>> E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate
>>> /usr/lib/x86_64-linux-gnu/libtiff5-alt
>
>> Yes, I'm afraid that's unavoidable. This issue is mentioned in the
>> README.Debian file. This works by installing the .so file in a
>> non-standard location so that it can coexist with libtiff4, and linking
>> in that way with libtool the rpath to be embedded. Once the tiff
>> transition is completed and the packages are rebuilt, this problem will
>> go away.
>
> This shouldn't be required, since the two libtiff shared libraries can
> both go into /usr/lib (since they have different SONAMEs). The only thing
> that can't go into /usr/lib and has to go somewhere else is the *.so
> symlink, which doesn't require an rpath setting, only a -L flag during
> linking.
The .so files (there are two libraries), static libraries, and .la files
are already the only files in a non-standard location. Basically only
the files whose names clash are in non-standard locations. (Tiff still
can't remove its .la file yet, or at least it couldn't though I can't
remember the exact details of when it's okay to remove the .la
file....it has a lot of reverse dependencies.... It's the only package
I maintain that still installs .la files.) I don't remember exactly
what is causing the rpath to appear, but I remember having investigated
it and determined, possibly incorrectly, that I couldn't fix it without
modifying libtool. I will give it another look. It is my recollection
that libtool is automatically adding the rpath when it finds the .so
file in a non-standard location since it assumes that the actual shared
library will be in the same directory as the .so file. In other words,
the rpath is not actually being used here....it is pointing to a place
where the libraries are not found. I am already adjusting the .so file
manually in the installation to ensure that it points to the correct
place:
$ dpkg --contents libtiff5-alt-dev_4.0.2-6_amd64.deb | fgrep .so
lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiff.so -> ../libtiff.so.5.1.0
lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiffxx.so -> ../libtiffxx.so.5.1.0
> See the krb5-multidev and heimdal-multidev packages for how this is done.
I'll give them a look and see if I can tell what they're doing
differently.
--
Jay Berkenbilt <qjb@debian.org>
Reply to: