Summary: | gnome-base/libgnomekbd-2.24.0: libgnomekbdui.so gets linked to old version of libgnomekbd.so | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcel Keller <marcel-k> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=580349 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
libgnomekbdui.so.3.0.0
build.log workdir after installation |
Description
Marcel Keller
2009-04-08 11:14:52 UTC
/me bets a buck on libtool 1.5 being the one to blame I'd like to see a readelf -d of the library or some other proof of that. I missed to save the library before I emerged again. But I'm sure that ldd said: libgnomekbd.so.2 => not found. ldd isn't a good source of information for this. It could very well have shown that another lib in the stack needed the old lib and hasn't been recompiled against the new version yet. It wouldn't be the same problem at all. I've now downgraded to libgnomekbd-2.22.0 and upgraded again, and I could reproduce the error. (BTW: Isn't it quite unlikely that libgnomekbdui depends on something that depends on libgnomekbd although libgnomekbdui and libgnomekbd are in the same package?) $ readelf -d libgnomekbdui.so Dynamic section at offset 0xed64 contains 67 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libatk-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libgnomekbd.so.2] 0x00000001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libgio-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libpangocairo-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libpangoft2-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libcairo.so.2] 0x00000001 (NEEDED) Shared library: [libpixman-1.so.0] 0x00000001 (NEEDED) Shared library: [libfontconfig.so.1] 0x00000001 (NEEDED) Shared library: [libfreetype.so.6] 0x00000001 (NEEDED) Shared library: [libexpat.so.1] 0x00000001 (NEEDED) Shared library: [libglitz-glx.so.1] 0x00000001 (NEEDED) Shared library: [libGL.so.1] 0x00000001 (NEEDED) Shared library: [libXmu.so.6] 0x00000001 (NEEDED) Shared library: [libXt.so.6] 0x00000001 (NEEDED) Shared library: [libSM.so.6] 0x00000001 (NEEDED) Shared library: [libICE.so.6] 0x00000001 (NEEDED) Shared library: [libXi.so.6] 0x00000001 (NEEDED) Shared library: [libXext.so.6] 0x00000001 (NEEDED) Shared library: [libglitz.so.1] 0x00000001 (NEEDED) Shared library: [libpng12.so.0] 0x00000001 (NEEDED) Shared library: [libXrender.so.1] 0x00000001 (NEEDED) Shared library: [libgconf-2.so.4] 0x00000001 (NEEDED) Shared library: [libORBit-2.so.0] 0x00000001 (NEEDED) Shared library: [libgmodule-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libgthread-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [librt.so.1] 0x00000001 (NEEDED) Shared library: [libdbus-glib-1.so.2] 0x00000001 (NEEDED) Shared library: [libnsl.so.1] 0x00000001 (NEEDED) Shared library: [libdbus-1.so.3] 0x00000001 (NEEDED) Shared library: [libxklavier.so.12] 0x00000001 (NEEDED) Shared library: [libxkbfile.so.1] 0x00000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libxml2.so.2] 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libX11.so.6] 0x00000001 (NEEDED) Shared library: [libXau.so.6] 0x00000001 (NEEDED) Shared library: [libXdmcp.so.6] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000e (SONAME) Library soname: [libgnomekbdui.so.3] 0x0000000c (INIT) 0x52b0 0x0000000d (FINI) 0xdc94 0x00000004 (HASH) 0xf4 0x6ffffef5 (GNU_HASH) 0xf8c 0x00000005 (STRTAB) 0x2690 0x00000006 (SYMTAB) 0x12c0 0x0000000a (STRSZ) 8254 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000003 (PLTGOT) 0xfff4 0x00000002 (PLTRELSZ) 2168 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x4a38 0x00000011 (REL) 0x4998 0x00000012 (RELSZ) 160 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x4948 0x6fffffff (VERNEEDNUM) 2 0x6ffffff0 (VERSYM) 0x46ce 0x6ffffffa (RELCOUNT) 4 0x00000000 (NULL) 0x0 Created attachment 187681 [details]
libgnomekbdui.so.3.0.0
ok I've tested this myself and it indeed relinks to .so.2. That sounds like a crazy libtool issue again. If anyone could post a full build.log, I could take a look at it to make sure that it is indeed a libtool bug. Thanks Created attachment 187832 [details]
build.log
@Marcel, This bug is getting _really_ tricky to track down. Could I ask you to do the following : - FEATURES="keepwork" emerge -1 libgnomekbd - cd /var/tmp/portage/gnome-base/ - tar -cjf libgnomekbd-2.24.0-workdir.tar.bz2 libgnomekbd-2.24.0/ And try to post this file somewhere public so I can really see what's going on on your system. @Gnome, my hunch now is that elibtoolize is actually breaking a perfectly good tarball... Thanks Oh, btw, I forgot to mention what the bug is in the build.log. Here's what can be found on line 273, starting at column 343 : -L/usr/lib -L/var/tmp/portage/gnome-base/libgnomekbd-2.24.0/image//usr/lib [...] -lgnomekbd So it's quite obvious why libgnomekbdui.so would link to the installed libgnomekbd.so ... Cheers Created attachment 187879 [details]
workdir after installation
I saw that there are two libgnomekbdui.so in libgnomekbd-2.24.0/libgnomekbd/.libs: libgnomekbdui.so.3.0.0 is linked correctly and libgnomekbdui.so.3.0.0T is not I have no idea what's going on and why this is happening. If I keep digging, I think I may pull my hair out. @Toolchain, could you guys take a look at this? I pretty much narrowed the bug down to the libtool call, but this is way out of my league. It's the first time I see this happening with a _libtool_2.2_ generated tarball. Any help with this would be greatly appreciated. Thanks the problem is the relinking step during install. libtool puts a -L path for /usr/lib before $D/usr/lib and so when libgnomekbdui gets relinked, it picks up the old lib in /usr/lib rather than the new one in $D/usr/lib. but libtool does this because it's doing what it's told ... i'm pretty sure this is just an error in libgnomekbd. you might want to apply this patch: --- libgnomekbd/Makefile.am +++ libgnomekbd/Makefile.am @@ -33,9 +33,9 @@ libgnomekbd_la_LIBADD = $(common_LIBADD) libgnomekbdui_la_LDFLAGS = $(common_LDFLAGS) -libgnomekbdui_la_LIBADD = $(common_LIBADD) \ - $(GTK_LIBS) \ - libgnomekbd.la +libgnomekbdui_la_LIBADD = libgnomekbd.la \ + $(common_LIBADD) \ + $(GTK_LIBS) libgnomekbd_la_SOURCES = \ gkbd-desktop-config.c \ since you arent already running autotools, it'll be a lot easier to patch Makefile.in ... the change will be exactly the same since libgnomekbdui_la_LIBADD is copied verbatim from Makefile.am to Makefile.in. Fixed in overlay. Thanks for reporting. I also applied this to 2.22 and 2.24 ebuilds without a bump. Thanks for reporting and thanks vapier for the solution. I think this breaks building with libtool-1.5.26, which is still the stable libtool. ok I'll have a lookg re-fixed in 2.24 and 2.26. Thanks. |