problematic shlibs entry in substvars file
I suspect this is another multiarch growing pains problem. I'm on
Debian Wheezy with multiarch enabled. I'm trying to understand a
packaging problem. I'm getting shlibs inserted in the
debian/package.substvars file and I can't understand why.
For example, lets rebuild the blt package.
$ apt-get source blt
$ cd blt-2.4z
$ dpkg-buildpackage -rfakeroot
The package builds, but when I try to install it, the system thinks I
don't have libc6-amd new enough. Like so:
$ sudo dpkg -i blt_2.4z-4.2_amd64.deb
[sudo] password for pauljohn:
(Reading database ... 393464 files and directories currently installed.)
Preparing to replace blt 2.4z-4.2 (using blt_2.4z-4.2_amd64.deb) ...
Unpacking replacement blt ...
dpkg: dependency problems prevent configuration of blt:
blt depends on libc6-amd64 (>= 2.7).
dpkg: error processing blt (--install):
dependency problems - leaving unconfigured
Processing triggers for doc-base ...
Processing 1 changed doc-base file...
Registering documents with scrollkeeper...
Processing triggers for man-db ...
Errors were encountered while processing:
blt
However, I do have libc6-amd MUCH NEWER than 2.7 (I'm multilib):
$ dpkg -l | grep libc6
ii libc6:amd64
2.13-37 amd64 Embedded GNU C
Library: Shared libraries
ii libc6:i386
2.13-37 i386 Embedded GNU C
Library: Shared libraries
ii libc6-amd64
2.13-37 i386 Embedded GNU C
Library: 64bit Shared libraries for AMD64
ii libc6-dbg:amd64
2.13-37 amd64 Embedded GNU C
Library: detached debugging symbols
ii libc6-dev:amd64
2.13-37 amd64 Embedded GNU C
Library: Development Libraries and Header Files
ii libc6-dev-i386
2.13-37 amd64 Embedded GNU C
Library: 32-bit development libraries for AMD64
ii libc6-i386
2.13-37 amd64 Embedded GNU C
Library: 32-bit shared libraries for AMD64
rc libc6-i686:i386
2.13-37 i386 Embedded GNU C
Library: Shared libraries [i686 optimized]
ii libc6-prof:amd64
2.13-37 amd64 Embedded GNU C
Library: Profiling Libraries
Partly I'm curious about that particular problem with blt, but more
generally, I'm curious about how/why the substvars file gets thusly:
$ cat debian/blt.substvars
shlibs:Depends=libc6-amd64 (>= 2.7), libx11-6, tcl8.5 (>= 8.5.0) |
tcl8.4 (>= 8.4.16), tk8.5 (>= 8.5.0) | tk8.4 (>= 8.4.16)
misc:Depends=
Why >= 2.7? Why libc6-amd64. AFAICT, it is not for the so files:
$ cat debian/blt/DEBIAN/shlibs
libBLTlite.2.4 8.5 blt (>= 2.4z-4.1)
libBLT.2.4 8.4 blt (>= 2.4z-4.1)
libBLT.2.4 8.5 blt (>= 2.4z-4.1)
libBLTlite.2.4 8.4 blt (>= 2.4z-4.1)
$ ldd debian/blt/usr/lib/libBLT.2.4.so.8.5
linux-vdso.so.1 => (0x00007fff6dbff000)
libtk8.5.so.0 => /usr/lib64/libtk8.5.so.0 (0x00007f88ca40e000)
libtcl8.5.so.0 => /usr/lib64/libtcl8.5.so.0 (0x00007f88ca0ee000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007f88c9db2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f88c9b30000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f88c9917000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f88c9713000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88c9389000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f88c916c000)
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
(0x00007f88c8f69000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x00007f88c8d56000)
libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
(0x00007f88c8b40000)
libfontconfig.so.1 =>
/usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f88c8909000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007f88c86e9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f88caaab000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x00007f88c8449000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x00007f88c8240000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f88c8028000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x00007f88c7dfe000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007f88c7bfb000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007f88c79f5000)
$ ldd debian/blt/usr/lib/libBLTlite.2.4.so.8.5
linux-vdso.so.1 => (0x00007fffb09ff000)
libtcl8.5.so.0 => /usr/lib64/libtcl8.5.so.0 (0x00007f3bc2354000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3bc20d2000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3bc1eba000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3bc1cb6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3bc192b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f3bc170f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3bc28dd000)
To create the shlibs dependency, I think dpkg-shlibdeps is reading
files in /var/lib/dpkg/info. I can't find any "2.7" associated with
libc6-amd in there.
And, if libc6-amd is really the i386 version of the C library supplied
on mutiarch systems, I don't really understand why the package is
trying to depend on it at all.
pj
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
Reply to: