Драсти Жоро. Минаха ми и тези неща през тиквичката.
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 ============================================================================
