Re: lug-bg: libgtk2.0-bin.deb undefined symbol
- Subject: Re: lug-bg: libgtk2.0-bin.deb undefined symbol
- From: peyo <peyo@xxxxxxxxx>
- Date: Wed, 29 Sep 2004 17:11:15 +0300
ldd /usr/bin/gtk-query-immodules-2.0
--------------------
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40018000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x402ef000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40360000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4037c000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x403a1000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x403a5000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x403ad000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x403bb000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x403cd000)
libz.so.1 => /usr/lib/libz.so.1 (0x4043b000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4044d000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40474000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x4047d000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40485000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4054c000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40552000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x4055e000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40593000)
libdl.so.2 => /lib/libdl.so.2 (0x40597000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x4059a000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x405d4000)
libm.so.6 => /lib/libm.so.6 (0x40654000)
libc.so.6 => /lib/libc.so.6 (0x40676000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x407a9000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x407c9000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/bin/gtk-query-immodules-2.0: file format elf32-i386
Contents of section .dynstr:
804852c 006c6962 67746b2d 7831312d 322e302e .libgtk-x11-2.0.
804853c 736f2e30 00675f64 69725f63 6c6f7365 so.0.g_dir_close
804854c 00675f73 7472696e 675f6672 65650067 .g_string_free.g
804855c 5f627569 6c645f66 696c656e 616d6500 _build_filename.
804856c 5f44594e 414d4943 00675f73 7472696e _DYNAMIC.g_strin
804857c 675f696e 73657274 5f630067 5f6d6f64 g_insert_c.g_mod
804858c 756c655f 6572726f 7200675f 73747269 ule_error.g_stri
804859c 6e675f6e 6577005f 696e6974 00675f64 ng_new._init.g_d
80485ac 69725f6f 70656e00 675f6469 725f7265 ir_open.g_dir_re
80485bc 61645f6e 616d6500 675f6861 73685f74 ad_name.g_hash_t
80485cc 61626c65 5f6c6f6f 6b757000 675f6d6f able_lookup.g_mo
80485dc 64756c65 5f636c6f 73650070 616e676f dule_close.pango
80485ec 5f73706c 69745f66 696c655f 6c697374 _split_file_list
80485fc 00675f68 6173685f 7461626c 655f6465 .g_hash_table_de
804860c 7374726f 7900675f 70617468 5f69735f stroy.g_path_is_
804861c 6162736f 6c757465 00675f6d 6f64756c absolute.g_modul
804862c 655f7379 6d626f6c 005f6669 6e690067 e_symbol._fini.g
804863c 5f737472 696e675f 61707065 6e640067 _string_append.g
804864c 5f737472 64757000 5f474c4f 42414c5f _strdup._GLOBAL_
804865c 4f464653 45545f54 41424c45 5f00675f OFFSET_TABLE_.g_
804866c 6d6f6475 6c655f6f 70656e00 675f6765 module_open.g_ge
804867c 745f6375 7272656e 745f6469 7200675f t_current_dir.g_
804868c 68617368 5f746162 6c655f6e 65775f66 hash_table_new_f
804869c 756c6c00 675f7374 725f6861 735f7375 ull.g_str_has_su
80486ac 66666978 00675f73 74725f68 61736800 ffix.g_str_hash.
80486bc 67746b5f 72635f67 65745f69 6d5f6d6f gtk_rc_get_im_mo
80486cc 64756c65 5f706174 68005f4a 765f5265 dule_path._Jv_Re
80486dc 67697374 6572436c 61737365 7300675f gisterClasses.g_
80486ec 7374725f 65717561 6c00675f 68617368 str_equal.g_hash
80486fc 5f746162 6c655f69 6e736572 74005f5f _table_insert.__
804870c 676d6f6e 5f737461 72745f5f 006c6962 gmon_start__.lib
804871c 67646b2d 7831312d 322e302e 736f2e30 gdk-x11-2.0.so.0
804872c 00675f66 7072696e 7466006c 69626174 .g_fprintf.libat
804873c 6b2d312e 302e736f 2e30006c 69626764 k-1.0.so.0.libgd
804874c 6b5f7069 78627566 2d322e30 2e736f2e k_pixbuf-2.0.so.
804875c 30006c69 62587261 6e64722e 736f2e32 0.libXrandr.so.2
804876c 006c6962 58692e73 6f2e3600 6c696258 .libXi.so.6.libX
804877c 6578742e 736f2e36 006c6962 5866742e ext.so.6.libXft.
804878c 736f2e32 006c6962 66726565 74797065 so.2.libfreetype
804879c 2e736f2e 36006c69 627a2e73 6f2e3100 .so.6.libz.so.1.
80487ac 6c696266 6f6e7463 6f6e6669 672e736f libfontconfig.so
80487bc 2e31006c 69625863 7572736f 722e736f .1.libXcursor.so
80487cc 2e31006c 69625872 656e6465 722e736f .1.libXrender.so
80487dc 2e31006c 69625831 312e736f 2e36006c .1.libX11.so.6.l
80487ec 69627061 6e676f78 66742d31 2e302e73 ibpangoxft-1.0.s
80487fc 6f2e3000 6c696270 616e676f 782d312e o.0.libpangox-1.
804880c 302e736f 2e30006c 69627061 6e676f2d 0.so.0.libpango-
804881c 312e302e 736f2e30 006c6962 676d6f64 1.0.so.0.libgmod
804882c 756c652d 322e302e 736f2e30 006c6962 ule-2.0.so.0.lib
804883c 646c2e73 6f2e3200 6c696267 6f626a65 dl.so.2.libgobje
804884c 63742d32 2e302e73 6f2e3000 6c696267 ct-2.0.so.0.libg
804885c 6c69622d 322e302e 736f2e30 00675f70 lib-2.0.so.0.g_p
804886c 72696e74 66006c69 626d2e73 6f2e3600 rintf.libm.so.6.
804887c 6c696263 2e736f2e 36007374 646f7574 libc.so.6.stdout
804888c 00737464 65727200 66707574 63005f49 .stderr.fputc._I
804889c 4f5f7374 64696e5f 75736564 005f5f6c O_stdin_used.__l
80488ac 6962635f 73746172 745f6d61 696e005f ibc_start_main._
80488bc 65646174 61005f5f 6273735f 73746172 edata.__bss_star
80488cc 74005f65 6e640047 4c494243 5f322e30 t._end.GLIBC_2.0
80488dc 00 .
Честно казано не виждам нищо нередно.
On Wednesday 29 September 2004 16:49, Peter Pentchev wrote:
> On Wed, Sep 29, 2004 at 04:45:36PM +0300, Peter Pentchev wrote:
> > On Wed, Sep 29, 2004 at 04:26:34PM +0300, peyo wrote:
> > [snip]
> >
> > > > Избери си някои от тези случаи защо се появява такава разлика между
> > > > тази и другите машини, имайки предвид, че /etc/ld.so.cache е
> > > > компилираната версия на /etc/ld.so.conf, след изпълнението на
> > > > ldconfig (опции) ... Понеже е девелоперска машина, може да си спомниш
> > > > как си изпълнявал ldconfig. А сигурно не стига до default path
> > > > /usr/lib, and then /lib , понеже открива нещо в /etc/ld.so.cache в
> > > > който може да си се намесил прибързано. Предположения само.
> > >
> > > Ясно. Всички тези варианти отпадат.
> > > Проиграх отново същото нещо, пак пуснах ldconfig- за да си компилира
> > > пак файла.
> > > Ядец.
> > > Определено не е това. Или поне симптомите не са точно такива.
> >
> > А я направи един бърз ldd /usr/bin/gtk-query-immodules-2.0 и кажи какво
> > показва... Чудя се дали е възможно самото това executable да е било
> > линкнато с допълнителни и явно неправилно -rpath опции: сега ако и някой
> > ми каже в коя секция на ELF формата се пази тази информация, че да можем
> > да направим и един objdump...
>
> Секцията би трябвало да бъде .dynstr; Пейо, можеш ли да направиш
>
> objdump -s -j .dynstr /usr/bin/gtk-immodules-2.0
>
> или ако това изреве, че нямаш секция .dynstr (крайно невероятно, но
> все пак знае ли човек)...
>
> objdump -h /usr/bin/gtk-immodules-2.0
>
> ...и оттам да си избереш някоя секцийка :)
>
> Поздрави,
> Петър
--
---
"Времето е еднопосочно.
Няма начин да се върнеш назад,
за да си допиеш."
***
Ако не отговарям на писмата Ви - погледнете тук: http://6lyokavitza.org/mail
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|