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): > > [EMAIL PROTECTED]:~> 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: > > [EMAIL PROTECTED]:~> 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
[EMAIL PROTECTED]:~> 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)
[EMAIL PROTECTED]:~> 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:
[EMAIL PROTECTED]:~> 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)
[EMAIL PROTECTED]:~> 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
pgp0L5IGf8iJm.pgp
Description: PGP signature
