"Bernhard R. Link" <[EMAIL PROTECTED]> (02/12/2007): > dpkg-shlibdeps misses some symbols and thus prints warnings about not > using symbols from a library even when doing so.
Yes, it does in some cases, but I'm not sure it is the case here. > but when I edit the binary to change the NEEDED section I get: > > | $ ldd -r debian/xbuffy/usr/bin/xbuffy > | libYaw.so.7 => not found > | libXt.so.6 => /usr/lib/libXt.so.6 (0xf7eb8000) > | libX11.so.6 => /usr/lib/libX11.so.6 (0xf7db4000) > | libc.so.6 => /lib/libc.so.6 (0xf7c40000) > | libSM.so.6 => /usr/lib/libSM.so.6 (0xf7c28000) > | libICE.so.6 => /usr/lib/libICE.so.6 (0xf7c00000) > | libXau.so.6 => /usr/lib/libXau.so.6 (0xf7bec000) > | libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf7bd8000) > | libdl.so.2 => /lib/libdl.so.2 (0xf7bc0000) > | /lib/ld-linux.so.2 (0xf7f2c000) > | undefined symbol: boxWidgetClass (debian/xbuffy/usr/bin/xbuffy) > | undefined symbol: commandWidgetClass (debian/xbuffy/usr/bin/xbuffy) The point here is “-r”. Both symbols are defined in /usr/lib/libXaw7.so.7.0.0, which gets recursively pulled in through libXaw; so I guess that dpkg-shlibdeps would like you to link against libXaw7 directly instead of linking against libXaw. > I'm missing a i386 unstable currently, but looking there at the binary > in etch, I think this will not be sparc specific at all. I gathered the above on i386. Nothing sparc-specific AFAICS. Cheers, -- Cyril Brulebois
signature.asc
Description: Digital signature
