Control: user d...@packages.debian.org
Control: usertags -1 dpkg-shlibdeps
Hi!
On Fri, 2015-07-03 at 16:28:51 +0200, Matthias Klose wrote:
> Package: dpkg-dev
> Version: 1.18.1
> dpkg-gensymbols generates wrong dependencies for multilib packages when no
> symbols file is present:
>
> $ fakeroot dpkg-shlibdeps -v -Tdebian/libx32cilkrts5.substvars
> -l/scratch/packages/gcc/5/gcc-5-5.1.1/debian/libx32gcc1/usr/libx32
> -l/scratch/packages/gcc/5/gcc-5-5.1.1/debian/libx32stdc\+\+6/usr/share/gdb/auto-load/usr/libx32
> -l/scratch/packages/gcc/5/gcc-5-5.1.1/debian/libx32stdc\+\+6/usr/libx32
> -l/scratch/packages/gcc/5/gcc-5-5.1.1/debian/libx32stdc\+\+6/usr/libx32
> -l/lib/x86_64-linux-gnux32 -l/usr/lib/x86_64-linux-gnux32 -l/libx32
> -l/usr/libx32 debian/libx32cilkrts5/usr/libx32/libcilkrts.so.5.0.0
> >> Scanning debian/libx32cilkrts5/usr/libx32/libcilkrts.so.5.0.0 (for Depends
> >> field)
> Library libdl.so.2 found in /libx32/libdl.so.2
> Library libpthread.so.0 found in /libx32/libpthread.so.0
> Library libstdc++.so.6 found in debian/libx32stdc++6/usr/libx32/libstdc++.so.6
> Library libm.so.6 found in /libx32/libm.so.6
> Library libc.so.6 found in /libx32/libc.so.6
> Library libgcc_s.so.1 found in debian/libx32gcc1/usr/libx32/libgcc_s.so.1
> Using symbols file /var/lib/dpkg/info/libc6-x32.symbols for libc.so.6
> Using symbols file /var/lib/dpkg/info/libc6-x32.symbols for libdl.so.2
> No associated package found for debian/libx32gcc1/usr/libx32/libgcc_s.so.1
> Using symbols file debian/lib32gcc1/DEBIAN/symbols for libgcc_s.so.1
> Using symbols file /var/lib/dpkg/info/libc6-x32.symbols for libpthread.so.0
> No associated package found for debian/libx32stdc++6/usr/libx32/libstdc++.so.6
> Using symbols file debian/lib32stdc++6/DEBIAN/symbols for libstdc++.so.6
> Using symbols file /var/lib/dpkg/info/libc6-x32.symbols for libm.so.6
> […]
> Calling with -S to find the correct library doesn't help. The problem seems to
> be that both libx32gcc1 and lib32stdc++6 don't have a symbols file, and
> dpkg-shlibdeps ignores the shlibs file in the correct package directory.
> […]
dpkg-shlibdeps prefers symbols files over anything else, then shlibs
files. It also implicitly adds all debian/*/DEBIAN/symbols and
debian/*/DEBIAN/shlibs to the search lists, so that when there is a
non-installed being-built package with a missing symbols file, it will
try all other being-built packages, and after that it will look for
shlibs. So this is another quirk of multilib, that it is tripping on.
(As a reference for future-self:
sub find_symbols_file() {
…
# Fallback to other symbols files but it shouldn't be necessary
push @files, @pkg_symbols;
…
}
)
> I assume an option to delimit the search for symbols files would help. Of
> course
> adding symbols files for every multilib works around the issue.
Making dpkg-shlibdeps prefer the shlibs file from a being-built package
when it is missing the symbols file, might seem like the sanest option,
unfortunately the current behavior is pretty old (since the introduction
of symbols files), so I'm afraid changing that could break stuff,
although I'm doubtful. I'll have to think a bit about it.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
