http://bugzilla.novell.com/show_bug.cgi?id=623215 http://bugzilla.novell.com/show_bug.cgi?id=623215#c9 --- Comment #9 from Michael Andres <ma@novell.com> 2010-08-11 18:38:27 CEST --- A) yast and zypper both use libzypp to download the files, and it's libzypp that does this checksum check by calling functions from libssl to compute the downloaded files checksums. This computation seems to fail and returns an empty checksum: "but the current checksum is <missing>." Given this, it is very unlikely that zypper and yast show different behavior! (unless you're using some strangely configured selfcompiled versions) To be sure about this, you should 'rm -rf /var/cache/zypp/raw/Compiz', then do a 'zypper refresh Compiz' to be sure zypper doewnloads and checks the files. If zypper succeeds delete the directory again and try Yast. B) Hard to tell from here, what the problem with your libstdc++.so.6.0.14 and maybe other libs is. A few things to check: 1)$ ls -l /usr/{local/,}lib64/libstdc++* This should always show something like this (maybe more/less): /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.14* /usr/lib64/libstdc++.so.6.0.14* There should always be one or more .so files with 3 digit versions, and a symlink for each major number (here 6) pointing to the highest version of this major number. Those symlinks are created/maintained whenever you call '/sbin/ldconfig' (or ldconfig -v). So whenever you copy/move shared libs around in your system manually, call ldconfig to adjust the symlinks. Otherwise ld.so may not be able to pick the right one. 2) Be sure not to accidentally copy 64-bit libs into some /lib/, or 32-bit libs into some 'lib64' directory. In doubt use the command 'file <lib>' to test. It will tell either 'ELF 32-bit LSB' or 'ELF 64-bit LSB'. Unless you altered the ld.so configuration (something you should not do), libs below /usr/local/lib64 are considered before /usr/lib64. As you describe the error ld.so found something at /usr/local/lib64/libstdc++.so.6 which somehow claimed to be a 6.0.14, but was not. As /usr/local is a location that is not touched by any of our packages, it must have been something you manually compiled or installed. Copying a real 6.0.14 to that location fixed the problem. Vice versa: If you habve the right libstdc++ packages installed (in /usr/lib64), and the symlinks below /usr/lib64/ are ok, then you should also be able to remove /usr/lib64/libstdc++*. You can use 'ldd' on any program or library to see which shared libs will be used at runtime. E.g: $ ldd /usr/lib64/YaST2/plugin/libpy2qt.so.2 linux-vdso.so.1 => (0x00007fff56f5d000) libyui.so.3 => /usr/lib64/libyui.so.3 (0x00007f80fdc71000) libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007f80fd83a000) libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x00007f80fccab000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f80fcaa7000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f80fc76a000) ... This may help you to identify the libs which are actually used. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.