Comment 12 for bug 6909

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 03:25:39 +0200
From: Goswin von Brederlow <email address hidden>
To: Arnaud Vandyck <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256978: kaffe: Problem of the lib path

Arnaud Vandyck <email address hidden> writes:

> Goswin Brederlow <email address hidden> writes:
>
>> as you said in your last message "/usr/lib/." is a valid library patch
>> on its own.
>>
>> The problem arises with libtool checking the lib path against the
>> system paths to see if rpath will be needed or not. Since "/usr/lib/."
>> is not one of the standard search path libtool will use rpath for this
>> library. That on its own is buggy but does not stop the binaries from
>> working.
>>
>> But the problem becomes even more serious when dpkg-shlibdeps tries to
>> calculate shared library dependancies. dpkg-shlibdeps compares the
>> output from ldd (which includes the rpath /usr/lib/./) with dpkgs file
>> database to find packages providing the library, which fails because
>> dpkg has no . in there. Hence the missing Depends.
>>
>> On amd64 the lib path is even more strange: /usr/lib/../lib64. Since
>> lib64 is a link to lib that ends up in the right place but again
>> libtool and dpkgs file database won't work with that path.
>
>
> Do you mean a temporary work around could be to hard copy dependencies
> and not let them automatically be filled by dpkg-shlibdeps?
>
> Thanks for your help,
>
> Cheers,

How about a shlibs.local file containing the libfii2-dev package for
the libffi2 lib with the broken rpath? That should fix the problem now
and get ignored when libffi2-dev gets fixed.

Haven't tested that though.

MfG
        Goswin