Comment 10 for bug 6909

Message-ID: <email address hidden>
Date: Tue, 06 Jul 2004 22:27:12 +0200
From: Arnaud Vandyck <email address hidden>
To: Goswin Brederlow <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256978: kaffe: Problem of the lib path

--=-=-=

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,

--
Arnaud Vandyck

This is Unix we're talking about, remember. It's not supposed to be
nice for the applications programmer.
  -- Matthew Danish on debian-devel

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA6wsi4vzFZu62tMIRAiQaAJ4ir4ozPZvya9ipRGWJLmuaV1ZU7ACgp4sx
fOrK8IVSfvp9DzccgreCBeg=
=9+8x
-----END PGP SIGNATURE-----
--=-=-=--