On Saturday 18 November 2006 15:31, Carl Hartung wrote:
On Saturday 18 November 2006 16:06, John Andersen wrote: <snip>
This is a x86_64 machine (core 2 duo) which means there is a 64bit libpng and a 32bit libpng installed (one in /lib64 and the other in /lib) if that makes any difference.
Addendum:
You can check which libraries are linked to your selected style using ldd like this (example uses keramik style):
carl@linux:~> ldd /opt/kde3/lib/kde3/plugins/styles/keramik.so linux-gate.so.1 => (0xffffe000) libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0x4005b000) libqt-mt.so.3 => /usr/lib/qt3/lib/libqt-mt.so.3 (0x40088000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40783000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40791000) libc.so.6 => /lib/tls/libc.so.6 (0x4086d000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4098c000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40a85000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40a98000) libm.so.6 => /lib/tls/libm.so.6 (0x40aa0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40ac6000) Note this: libpng.so.3 => /usr/lib/libpng.so.3 (0x40ad1000) And this: libz.so.1 => /lib/libz.so.1 (0x40b10000) <snip>
You can use the "file" command to discern if a file is 32-bit or 64-bit like this:
carl@linux:~> file /opt/kde3/lib/kde3/plugins/styles/keramik.so /opt/kde3/lib/kde3/plugins/styles/keramik.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
Finally, it appears the error message you're getting is sometimes caused when libpng can't uncompress the data because libz is not working correctly (wrong version, bad link and can't be found, etc.)
---- Carl Here's what I get (snipped at about the same place as your example above jsa@nordell:~> ldd /opt/kde3/lib/kde3/plugins/styles/keramik.so linux-gate.so.1 => (0xffffe000) libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0xf7e87000) libqt-mt.so.3 => /usr/lib/qt3/lib/libqt-mt.so.3 (0xf779f000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xf7791000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf76b1000) libc.so.6 => /lib/libc.so.6 (0xf7590000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xf7499000) libpthread.so.0 => /lib/libpthread.so.0 (0xf7485000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xf747d000) libm.so.6 => /lib/libm.so.6 (0xf7458000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf744d000) libpng.so.3 => /usr/lib/libpng.so.3 (0xf740d000) libz.so.1 => /lib/libz.so.1 (0xf73fb000) jsa@nordell:~> file /opt/kde3/lib/kde3/plugins/styles/keramik.so /opt/kde3/lib/kde3/plugins/styles/keramik.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped However, since this is a 64bit machine I also checked the 64bit version or keramic: jsa@nordell:~> ldd /opt/kde3/lib64/kde3/plugins/styles/keramik.so libkdefx.so.4 => /opt/kde3/lib64/libkdefx.so.4 (0x00002b987678b000) libqt-mt.so.3 => /usr/lib/qt3/lib64/libqt-mt.so.3 (0x00002b98768b9000) libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x00002b987722d000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b987733f000) libc.so.6 => /lib64/libc.so.6 (0x00002b9877540000) libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x00002b9877770000) libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1 (0x00002b987797f000) libm.so.6 => /lib64/libm.so.6 (0x00002b9877a88000) libpng.so.3 => /usr/lib64/libpng.so.3 (0x00002b9877bdd000) libz.so.1 => /lib64/libz.so.1 (0x00002b9877d1a000) jsa@nordell:~> file /opt/kde3/lib64/kde3/plugins/styles/keramik.so /opt/kde3/lib64/kde3/plugins/styles/keramik.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Then I decided to see which one was actually used. So I did some digging thru the Strace of a konsole launch. I can clearly see it using the 64bit libs, as this example shows: (I'm sending unwrapped, but it will probably wrap and make a mess outo of it., The first line is the important bit showing the call was to lib64/libpng: open("/usr/lib64/libpng.so.3", O_RDONLY) = 3 <======== 64bit read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0Px\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=247744, ...}) = 0 mmap(NULL, 1293800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ab92243d000 madvise(0x2ab92243d000, 1293800, MADV_SEQUENTIAL|0x1) = 0 mprotect(0x2ab922478000, 1048576, PROT_NONE) = 0 mmap(0x2ab922578000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b000) = 0x2ab922578000 close(3) = 0 Then I looked in strace for a typical access to a png file of a theme: access("/opt/kde3/share/icons/hicolor/16x16/apps/konsole.png", R_OK) = 0 <========= lays to rest theory of missing pngs open("/opt/kde3/share/icons/hicolor/16x16/apps/konsole.png", O_RDONLY) = 11 fstat(11, {st_mode=S_IFREG|0644, st_size=826, ...}) = 0 fstat(11, {st_mode=S_IFREG|0644, st_size=826, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab923d4c000 lseek(11, 0, SEEK_SET) = 0 read(11, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\20\0\0\0\20\10\6\0\0"..., 4096) = 826 write(2, "libpng error: Invalid image widt"..., 34libpng error: Invalid image width <======= There is is... ) = 34 close(11) = 0 Finally your suggestion about libz... I looked in the strace for that and found that it looked long and hard to find this checking first under kde, then under qt3 and finally found it in /lib64 So that tells me it is using the 64 bit routines, and it is finding the actual png file. But it doesn't tell me why its crapping out. -- _____________________________________ John Andersen