Re: lug-bg: libgtk2.0-bin.deb undefined symbol

[peyo <peyo@xxxxxxxxx>]

Драсти Жоро.

Минаха ми и тези неща през тиквичката. 

On Wednesday 29 September 2004 16:12, George Danchev wrote:
> On Wednesday 29 September 2004 15:21, peyo wrote:
>
> Драсте,
>
> > Само едно не ми е ясно.... как така досега линкера не е изревал за нещо
> > друго. Както и да е. Благодаря за помощта отново. И никога не забравяйте
> > да си описвате прилежно и читаво envvars.
> >
> > P.S.
> > Което ме навежда на мисълта, че туй чудо не използва ld -to.
>
> Значи за динамично свързаните приложения, имаме 2 (run-time) dynamic
> linker-a: /lib/ld.so - dynamic linker за A.OUT формата - имащ вече само
> историческа или музейнo-експонатна стойност.
> /lib/ld-linux.so.2 - dynamic linker за ELF формата.

че е elf - спор няма

>
> file /usr/bin/gtk-query-immodules-2.0 казва, че си имаме работа с еди киф
> си ЕЛФ, а ldd /usr/bin/gtk-query-immodules-2.0, че използва дайнамик
> линкера  /lib/ld-linux.so.2 и се свързва с еди какво си там.
>
> > Ма как пък няма да го използва, когато пък всички  elf бинарита, дето
> > използват тази библиотека използват точно пък същия линкер. Брех чудо
> > невиждано.....
> >
> > Те ти тема за размисъл за пропушилият ми мозък. Ка'т си нямаме проблеми -
> > дай да си ги създаваме сами.
> >
> > P.P.S
> > Все пак всичко си е надлежно написано в ld.so.conf . Големият въпрос е:
> > Защо, когато е установило, че LD_LIBRARY_PATH е празна, не е потърсило
> > във въпросният файл и от там да си зареди директорийките. Още една тема
> > за размисъл. И защо на съседната машина без да е пълна променливата, си
> > се справя отлично.
>

>      The necessary shared libraries needed by the program are searched for
> in the following order
>
>        o      Using  the  environment  variable  LD_LIBRARY_PATH
> (LD_AOUT_LIBRARY_PATH for a.out programs).
>               Except if the executable is a setuid/setgid binary, in which
> case it is ignored.
 
>
>        o      From the cache file /etc/ld.so.cache which contains a
> compiled list  of  candidate  libraries
>               previously found in the augmented library path.

>
>        o      In the default path /usr/lib, and then /lib.

>
> Избери си някои от тези случаи защо се появява такава разлика между тази и
> другите машини, имайки предвид, че  /etc/ld.so.cache е компилираната версия
> на  /etc/ld.so.conf, след изпълнението на ldconfig (опции) ... Понеже е
> девелоперска машина, може да си спомниш как си изпълнявал ldconfig. А
> сигурно не стига до default path /usr/lib, and then /lib , понеже открива
> нещо в  /etc/ld.so.cache в който може да си се намесил прибързано.
> Предположения само.

Ясно. Всички тези варианти отпадат. 
Проиграх отново същото нещо, пак пуснах ldconfig- за да си компилира пак 
файла.  
Ядец.  
Определено не е това. Или поне симптомите не са точно такива. 

Според ман-а, би трябвало да работи без грешка. Знам. Но в момента, в който 
разкарам въпросната променлива(изчистя я), се получава същата свинщина. 

Продължавам с гледането. Сега gdb-двам линкера ко прави.
Сигурно е някъде нещо много просто. 


-- 
---
"Времето е еднопосочно. 
Няма начин да се върнеш назад,
за да си допиеш."
***
Ако не отговарям на писмата Ви - погледнете тук: 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
============================================================================