Bug#317082: Not just a dpkg bug

["Nikita V. Youshchenko" <yoush@debian.org>]

> On Tue, Jan 24, 2006 at 06:05:43PM +0300, Nikita V. Youshchenko wrote:
> > > On Sun, Jan 22, 2006 at 10:14:16PM +0100, Frank Lichtenheld wrote:
> > > Comment to myself: The current patch probably breaks dh_shlibdeps
> > > -l option because it doesn't honor LD_LIBRARY_PATH. Can someone
> > > tell me a package which really needs this option? The ones that
> > > I tested so far seem to build equally fine without it...
> >
> > This option wasneeded when package builds a binary that uses libraries
> > built from the same source package. In this case, libraries may not be
> > available outside of package build directory; so ldd called from
> > dpkg-shlibdeps won't find them witout LD_LIBRARY_PATH.
> >
> > Don't yet know how this situation is handled in your patched
> > dpkg-shlibdeps...
>
> Hmm, but dpkg-shlibdeps already tries to take care of this by using
> all local shlibs files. Can someone point me to a package that really
> misbuilds without -l ? This would really help me to understand the
> real problem.

dpkg-shlibdeps calls ldd, which will just fail if LD_LIBRARY_PATH won't 
point to directories with local libraries.

    defined($c= open(P,"-|")) || syserr("cannot fork for ldd");
    if (!$c) { exec("ldd","--",$exec[$i]); syserr("cannot exec ldd"); }
    while (<P>) {
        if (m,^\s+(\S+)\s+=>\s+(\S+)\s+\(0x.+\)?$,) {
            $so2path{$1} = $2;
        }
    }
    close(P); $? && subprocerr("ldd on \`$exec[$i]'");

If I understand this code correctly, it will go to subprocerr() and die if 
ldd returns non-zero.

Any package that uses local libs will be affected. E.g. zlib (if built in 
environment where zlib is not yet installed).