[arch-general] Perplexing libjpeg-related packaging issue
Hi guys. Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64 there are no problems, and everything works as expected; this is not the case for i686, where there's a strange problem: [root@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb7f1c000) libjpeg.so.62 => not found The package was created with makechrootpkg in a clean chroot. How is it even possible to link with two different versions of the same library? And where did it get the old version, since it didn't exist in the chroot? I'm trying to rebuild a sane version now, but if anybody has a clue I'd be happy to hear it :P Corrado
2009/7/15 bardo <ilbardo@gmail.com>:
The package was created with makechrootpkg in a clean chroot. How is it even possible to link with two different versions of the same library? And where did it get the old version, since it didn't exist in the chroot?
I may start to understand... The command I posted was from a vitual machine that I didn't fully upgrade, I just fired it up to check a user claim of the problem. So... it seems that ldd reports shared libraries for dependencies, and there was something not fully upgraded that still looked for libjpeg.so.62: after a full upgrade of the system the problem disappeared. Is that possible? Corrado
bardo schrieb:
Hi guys. Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64 there are no problems, and everything works as expected; this is not the case for i686, where there's a strange problem:
[root@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb7f1c000) libjpeg.so.62 => not found
Do not consult ldd here, but readelf -d. I suspect this will only show .so.7. ldd works recursively when resolving link dependencies.
Thomas Bächler wrote:
bardo schrieb:
Hi guys. Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64 there are no problems, and everything works as expected; this is not the case for i686, where there's a strange problem:
[root@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb7f1c000) libjpeg.so.62 => not found
Do not consult ldd here, but readelf -d. I suspect this will only show .so.7. ldd works recursively when resolving link dependencies.
If a full update does not help, you might want to try lddd from devtools to try and find what is still using libjpeg6. Allan
2009/7/15 Allan McRae <allan@archlinux.org>:
If a full update does not help, you might want to try lddd from devtools to try and find what is still using libjpeg6.
It worked for me, but it seems it did not for the user, so I'm waiting to know which mirror he uses and readelf's output. Corrado
2009/7/15 bardo <ilbardo@gmail.com>:
It worked for me, but it seems it did not for the user, so I'm waiting to know which mirror he uses and readelf's output.
He uses archlinux.puzzle.ch... I had problems in the last few days with it too, so I switched to another one, maybe this caused the issue. Anyway, here's readelf's output: ----- Dynamic section at offset 0x31d05c contains 34 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libbz2.so.1.0] 0x00000001 (NEEDED) Shared library: [libgd.so.2] 0x00000001 (NEEDED) Shared library: [libjpeg.so.62] 0x00000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x00000001 (NEEDED) Shared library: [libfreetype.so.6] 0x00000001 (NEEDED) Shared library: [libpng12.so.0] 0x00000001 (NEEDED) Shared library: [libmagic.so.1] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000c (INIT) 0x804c9f8 0x0000000d (FINI) 0x83468ac 0x00000004 (HASH) 0x8048168 0x6ffffef5 (GNU_HASH) 0x8048b78 0x00000005 (STRTAB) 0x804a510 0x00000006 (SYMTAB) 0x8048d60 0x0000000a (STRSZ) 5312 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x83661dc 0x00000002 (PLTRELSZ) 2616 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x804bfc0 0x00000011 (REL) 0x804be78 0x00000012 (RELSZ) 328 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x804bcc8 0x6fffffff (VERNEEDNUM) 7 0x6ffffff0 (VERSYM) 0x804b9d0 0x00000000 (NULL) 0x0 ----- It indeed points to .62, but on my installation the same binary does not! I'm not very familiar with readelf, could you please clarify if the output is right? Corrado
bardo wrote:
2009/7/15 bardo <ilbardo@gmail.com>:
It worked for me, but it seems it did not for the user, so I'm waiting to know which mirror he uses and readelf's output.
He uses archlinux.puzzle.ch... I had problems in the last few days with it too, so I switched to another one, maybe this caused the issue. Anyway, here's readelf's output:
----- Dynamic section at offset 0x31d05c contains 34 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libbz2.so.1.0] 0x00000001 (NEEDED) Shared library: [libgd.so.2] 0x00000001 (NEEDED) Shared library: [libjpeg.so.62] 0x00000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x00000001 (NEEDED) Shared library: [libfreetype.so.6] 0x00000001 (NEEDED) Shared library: [libpng12.so.0] 0x00000001 (NEEDED) Shared library: [libmagic.so.1] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000c (INIT) 0x804c9f8 0x0000000d (FINI) 0x83468ac 0x00000004 (HASH) 0x8048168 0x6ffffef5 (GNU_HASH) 0x8048b78 0x00000005 (STRTAB) 0x804a510 0x00000006 (SYMTAB) 0x8048d60 0x0000000a (STRSZ) 5312 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x83661dc 0x00000002 (PLTRELSZ) 2616 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x804bfc0 0x00000011 (REL) 0x804be78 0x00000012 (RELSZ) 328 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x804bcc8 0x6fffffff (VERNEEDNUM) 7 0x6ffffff0 (VERSYM) 0x804b9d0 0x00000000 (NULL) 0x0 -----
It indeed points to .62, but on my installation the same binary does not! I'm not very familiar with readelf, could you please clarify if the output is right?
Strange - both using the same architecture?
2009/7/15 Allan McRae <allan@archlinux.org>:
Strange - both using the same architecture?
Yes, i686, but just to be sure I checked on both arches, and I get the new version.
2009/7/15 bardo <ilbardo@gmail.com>:
Yes, i686, but just to be sure I checked on both arches, and I get the new version.
The problem has been solved by switching repos. Could it be that mldonkey just linked to libjpeg.so, and readelf recurred to libjpeg.so.62, while the program said it didn't find the library because the internal offset was for another version?
bardo schrieb:
2009/7/15 bardo <ilbardo@gmail.com>:
Yes, i686, but just to be sure I checked on both arches, and I get the new version.
The problem has been solved by switching repos. Could it be that mldonkey just linked to libjpeg.so, and readelf recurred to libjpeg.so.62, while the program said it didn't find the library because the internal offset was for another version?
What readelf said is what is written in the binary. If the binary says libjpeg.so.62, then it's an old binary!
2009/7/15 Thomas Bächler <thomas@archlinux.org>:
What readelf said is what is written in the binary. If the binary says libjpeg.so.62, then it's an old binary!
You're right. I reverted back to the puzzle.ch mirror and I saw it didn't sync properly, it still has the old mldonkey. Thanks for clarifications =) Corrado
participants (3)
-
Allan McRae
-
bardo
-
Thomas Bächler