[devel] rpmelfsym [2]

[devel] rpmelfsym [2]

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 7547 bytes --]

On Tue, Sep 13, 2005 at 07:49:49PM +0400, Alexey Tourbin wrote:
> $ find /bin /usr/bin /lib /usr/lib -type f -maxdepth 1 |file -f - |awk -F': +' '$2~/ELF.*(dynamic|shared)/{print$1}' |xargs nm -D |awk 'NF>1{print NF-1,$(NF-1)}' |sort |uniq -c |sort -n
>      25 2 a
>      54 1 v
>    5864 1 w
>    6488 2 R
>    9310 2 A
>   24821 2 D
>   27751 2 B
>   38616 2 V
>   65737 2 W
>  236795 1 U
>  359673 2 T
> $

> Зато "буквы" не "пересекаются" по наличию или отсутствию адреса.
> То есть отдельное поле в дампе для "есть адрес/нет адреса" не нужно.
> Наверное, это банальная истина, но вот я её с понтом проверил.

Итого, получен (почти) полный дамп всех ELF-символов сизифа, в следующем
виде:

$ pwd
/home/at/.qa-robot/rpmelfsym
$ du -hs dump.old
350M    dump.old
$ head dump.old
7colors /usr/bin/sevencolors    A       _DYNAMIC
7colors /usr/bin/sevencolors    A       _GLOBAL_OFFSET_TABLE_
7colors /usr/bin/sevencolors    A       __bss_start
7colors /usr/bin/sevencolors    A       _edata
7colors /usr/bin/sevencolors    A       _end
7colors /usr/bin/sevencolors    B       game
7colors /usr/bin/sevencolors    D       __data_start
7colors /usr/bin/sevencolors    D       options
7colors /usr/bin/sevencolors    D       rhomb_xpm_data
7colors /usr/bin/sevencolors    R       _IO_stdin_used
$

Как видно из списка выше, буковки [AaBDRTVW] имеют адрес, то есть в
принципе эти символы кем-то могут провайдиться.  Буковки [Uvw] не имеют
адреса, то есть эти символы "оживают" в процессе динамической линковки.

Теперь следите за моей логикой.  Буковки, которые имеют адрес,
складываем в кучку provides.  Остальные буковки по смыслу ложатся в
кучку requires.  Далее нужно сравнивнить эти две кучки: символы, которые
есть в кучке requires, но которые отсутствуют в кучке provides, ЗАВЕДОМО
не могут правильно резольвиться динамическим линкером.

Это правило -- СЛАБОЕ правило в том смысле, что позволяет обнаружить
только ЯВНЫЕ, ЗАВЕДОМО недопустимые, ошибочные символы в ELF'ах.  Оно
не учитывает связи между ELF'ами, попросту допуская, что при совпадении
символов в requires и provides нужная связь между ELF'ами имеется.

Для requires и provides буду использовать обозначения "ref" и "def"
соответственно (как в lorder из v7).

$ awk -F'\t' '$3~/[AaBDRTVW]/' dump.old >def
$ awk -F'\t' '$3~/[Uvw]/' dump.old >ref

Проверяем, не осталось ли за бортом других буковок.

$ wc -l dump.old def ref
  4897331 dump.old
  2793772 def
  2103559 ref
  9794662 total
$ echo $(( 2793772 + 2103559 ))
4897331
$

Не осталось.  Теперь нужно отыскать символы в кучке "ref", которые не
"спариваются" с символами в кучке "def".  Это умеет делать join.  Для
этого нужно предварительно отсортировать def и ref по ключевому полю,
т.е. по символам (последнее поле, #4).

$ sort -t$'\t' -k4,4 -o def def & sort -t$'\t' -k4,4 -o ref ref &
[1] 15993
[2] 15994
$ man join

(sort тормознуто сортирует, читаю man join)

[2]  + done       sort -t$'\t' -k4,4 -o ref ref
[1]  + done       sort -t$'\t' -k4,4 -o def def
$ join -t$'\t' -j 4 -v 1 ref def -o '1.1 1.2 1.3 1.4' >join.out
$ wc -l join.out
18243 join.out
$

Есть такие символы!

$ head -20 join.out
tomboy	/usr/lib/tomboy/libtomboy.so	U	GTK_IS_SOURCE_VIEW
directfb	/usr/lib/directfb-0.9.21/gfxdrivers/libdirectfb_nsc.so	U	Gal_set_source_transparency
libcdf	/usr/lib/libcdf_idl.so.0.0.0	U	IDL_MakeTempArray
libcdf	/usr/lib/libcdf_idl.so.0.0.0	U	IDL_StoreScalar
libcdf	/usr/lib/libcdf_idl.so.0.0.0	U	IDL_StrDelete
libcdf	/usr/lib/libcdf_idl.so.0.0.0	U	IDL_StrStore
libcdf	/usr/lib/libcdf_idl.so.0.0.0	U	IDL_VarCopy
libgcj3.4	/usr/lib/lib-gnu-java-awt-peer-gtk.so.5.0.0	U	LINK_ReallyLinkClass
libgcj3.4-debug	/usr/lib/debug/lib-gnu-java-awt-peer-gtk.so.5.0.0	U	LINK_ReallyLinkClass
libgcj3.4	/usr/lib/lib-gnu-java-awt-peer-gtk.so.5.0.0	U	LINK_ReallyLinkKnownClass
libgcj3.4-debug	/usr/lib/debug/lib-gnu-java-awt-peer-gtk.so.5.0.0	U	LINK_ReallyLinkKnownClass
mod_ssl-sxnet	/usr/lib/apache/mod_sxnet.so	U	Malloc
mnogosearch-ruby	/usr/lib/ruby/vendor_ruby/1.8/i586-linux-gnu/mnogo.so	U	UdmEnvErrCode
abiword	/usr/lib/AbiWord-2.4/plugins/libAbiGimp.so	U	_Z10progExistsPKc
python-module-PyKDE	/usr/lib/python2.4/site-packages/kdeprint.so	U	_Z11rangeToSizeRK7QString
TORCS	/usr/lib/torcs/modules/graphic/ssggraph.so	U	_Z14ssgCullAndDrawP7ssgRoot
TORCS	/usr/lib/torcs/texmapper-bin	U	_Z14ssgCullAndDrawP7ssgRoot
boost-test	/usr/lib/libboost_unit_test_framework-gcc-1_32.so.1.32.0	U	_Z20init_unit_test_suiteiPPc
boost-test	/usr/lib/libboost_unit_test_framework-gcc-mt-1_32.so.1.32.0	U	_Z20init_unit_test_suiteiPPc
boost-test-devel	/usr/lib/libboost_unit_test_framework-gcc-d-1_32.so.1.32.0	U	_Z20init_unit_test_suiteiPPc
$

Похоже на правду.  По поводу GTK_IS_SOURCE_VIEW всё ясно -- это
нераскрытый макрос (в смысле препроцессора cpp).  По поводу
Gal_set_source_transparency -- проверяем:

$ grep -wi Gal_set_source_transparency dump.old
directfb        /usr/lib/directfb-0.9.21/gfxdrivers/libdirectfb_nsc.so	U       Gal_set_source_transparency
$

Нет такого символа в дампе.  Кто предоставляет символы Gal_*?

$ awk -F'\t' '$3=="T"&&$4~/^Gal_/' dump.old
directfb        /usr/lib/directfb-0.9.21/gfxdrivers/libdirectfb_nsc.so	T       Gal_bresenham_line
directfb        /usr/lib/directfb-0.9.21/gfxdrivers/libdirectfb_nsc.so	T       Gal_cleanup_interface
...
$

Ага, сам же directfb их и предоставляет.  Что-то в нём не стыкуется.

$ awk -F'\t' '$4~/^Gal_.*transp/' dump.old
directfb        /usr/lib/directfb-0.9.21/gfxdrivers/libdirectfb_nsc.so	U       Gal_set_source_transparency
$

Странно.  Ладно, едем дальше.  libcdf_idl, символы IDL_*.

$ awk -F'\t' '$3=="T"&&$4~/^IDL_/' dump.old
ORBit-devel     /usr/bin/orbit-idl      T	IDL_tree_traverse_parents
ORBit2-devel    /usr/bin/orbit-idl-2    T	IDL_tree_traverse_parents
ORBit2-devel    /usr/bin/orbit-idl-2    T	IDL_tree_traverse_parents_full
libIDL  /usr/lib/libIDL-2.so.0.0.0      T       IDL_attr_dcl_new
libIDL  /usr/lib/libIDL-2.so.0.0.0      T       IDL_binop_new
...
libORBit        /usr/lib/libIDL-0.6.so.0.4.4    T       IDL_attr_dcl_new
libORBit        /usr/lib/libIDL-0.6.so.0.4.4    T       IDL_binop_new
libORBit        /usr/lib/libIDL-0.6.so.0.4.4    T       IDL_boolean_new
libORBit        /usr/lib/libIDL-0.6.so.0.4.4    T	IDL_case_stmt_new
...
$

Ясно, это всякие ORBit'ы и IDL'и, но таких символов в них нету.  Странно.
Попробуем на всякий случай `ldd -r'.

$ ldd -r /usr/lib/libcdf_idl.so.0.0.0
        libc.so.6 => /lib/i686/libc.so.6 (0x4005d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: IDL_StoreScalar       (/usr/lib/libcdf_idl.so.0.0.0)
undefined symbol: IDL_VarCopy   (/usr/lib/libcdf_idl.so.0.0.0)
undefined symbol: IDL_StrStore  (/usr/lib/libcdf_idl.so.0.0.0)
undefined symbol: IDL_StrDelete (/usr/lib/libcdf_idl.so.0.0.0)
undefined symbol: IDL_MakeTempArray     (/usr/lib/libcdf_idl.so.0.0.0)
$

Круто!  Эта библиотека по части IDL_ ни с кем не слинкована, а вывод
`ldd -r' подтвержает то, что мы только что увидели в join.out.

По поводу libgcj3.4 я судить не берусь.
Дальше идет mod_ssl-sxnet Malloc.

$ grep -w Malloc dump.old
mod_ssl-sxnet   /usr/lib/apache/mod_sxnet.so    U       Malloc
$

Нет такого символа нигде!  Далее идёт boost -- опять же не берусь
судить.  Потом всякое приплюснутое.  И так далее.

...

Что делать будем?

PS: там дальше много всяких __gmon_start__ символов идёт, так что всё
не слишком плохо.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] ELF undefined references

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Sun, Sep 18, 2005 at 12:45:20AM +0400, Alexey Tourbin wrote:
> Что делать будем?

1. Включаем давилку undefined references.
2. Чиним сборочные сервера и воскрешаем тестирование Сизифа пересборкой.
3. Ждем N недель, по окончании которых основная проблема будет решена.

P.S. На днях из разговора с разработчиками из SuSE узнал, что у них
сборочная система ещё не ловит даже text relocations.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: ELF undefined references

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Sun, Sep 18, 2005 at 02:40:47AM +0400, Dmitry V. Levin wrote:
> P.S. На днях из разговора с разработчиками из SuSE узнал, что у них
> сборочная система ещё не ловит даже text relocations.

Это как раз менее актуально, потому что программа-таки работает, только
линкер трудится за двоих.  А c undefined references программа попросту
падает, причем не сразу, а в самом неожиданном месте, из-за lazy
relocations.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: ELF undefined references

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Sun, Sep 18, 2005 at 03:02:55AM +0400, Alexey Tourbin wrote:
> On Sun, Sep 18, 2005 at 02:40:47AM +0400, Dmitry V. Levin wrote:
> > P.S. На днях из разговора с разработчиками из SuSE узнал, что у них
> > сборочная система ещё не ловит даже text relocations.
> 
> Это как раз менее актуально, потому что программа-таки работает, только
> линкер трудится за двоих.

Нет, линкер не только тратит больше времени, но и вынужден превращать
страницы кодового сегмента в черти что, а это снижает безопасность.
А на некоторых архитектурах text relocations просто не реализованы.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: ELF undefined references

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Sun, Sep 18, 2005 at 03:16:38AM +0400, Dmitry V. Levin wrote:
> > > P.S. На днях из разговора с разработчиками из SuSE узнал, что у них
> > > сборочная система ещё не ловит даже text relocations.
> > 
> > Это как раз менее актуально, потому что программа-таки работает, только
> > линкер трудится за двоих.
> 
> Нет, линкер не только тратит больше времени, но и вынужден превращать
> страницы кодового сегмента в черти что, а это снижает безопасность.
> А на некоторых архитектурах text relocations просто не реализованы.

Ну да.  А некоторые программы просто не запускаются.  И об этом пишут
в рассылках: "запускаю то-то, получаю undefined symbol".  То есть это
разница между "работает" и "не работает", хотя и работать может кое-как.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: rpmelfsym [2]

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 808 bytes --]

On Sun, Sep 18, 2005 at 12:45:20AM +0400, Alexey Tourbin wrote:
> Теперь следите за моей логикой.  Буковки, которые имеют адрес,
> складываем в кучку provides.  Остальные буковки по смыслу ложатся в
> кучку requires.  Далее нужно сравнивнить эти две кучки: символы, которые
> есть в кучке requires, но которые отсутствуют в кучке provides, ЗАВЕДОМО
> не могут правильно резольвиться динамическим линкером.

По мотивам изложенного (с небольшими исправлениями) я зарядил робота.
Вот полный список ELF'ов, содержащих символы, которые заведомо не могут
правильно резольвиться динамическим линкером.  Эти пакеты попросту не
могут правильно работать -- они должны падать с диагностикой "undefined
symbol" либо сразу же (особенно с LD_BIND_NOW=1), или в "случайном"
месте через некоторое время работы.

[-- Attachment #1.2: bad_elfsym.gz --]
[-- Type: application/x-gzip, Size: 4227 bytes --]

[-- Attachment #1.3: bad_elf_symbols --]
[-- Type: text/plain, Size: 259 bytes --]

#!/bin/sh -ef

cd "${workdir:?}"
rpmelfsym -ap >sym
sort -o sym -u sym
awk -F'\t' '$3~/[AaBDRTVW]/' sym >def
awk -F'\t' '$3~/[Uv]/#w' sym >ref
sort -t$'\t' -k4,4 -o def def
sort -t$'\t' -k4,4 -o ref ref
join -t$'\t' -v1 -j 4 -o '1.1 1.2 1.3 1.4' ref def
cd -

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: rpmelfsym [2]

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Sat, Oct 01, 2005 at 07:05:57AM +0400, Alexey Tourbin wrote:
> По мотивам изложенного (с небольшими исправлениями) я зарядил робота.

> awk -F'\t' '$3~/[AaBDRTVW]/' sym >def
> awk -F'\t' '$3~/[Uv]/#w' sym >ref

[w] я убрал из списка ref, потому что большинство символов [w], которые
определяются как undefined, назызываются __gmon_start__.  [v] я тоже
склоняюсь убрать из списка ref, потому что [w] (weak symbol) и [v] (weak
object) -- это вроде как законный способ иметь undefined symbols в
бинаре.

Далее, уточняю буковки для списка def.  В nm(1) сказано:

	If lowercase, the symbol is local; if uppercase,
	the symbol is global (external).

Правильно я понимаю, что ни при каких обстоятельствах символы с
маленькой буковкой не могут быть кандидатами на динамическую линковку
за пределами отдельно взятого бинаря?  Нужно рассмотреть все случаи.

Если это так, то в списке def должно остаться [A-TV-Z].

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] dante-server /usr/sbin/sockd U eval_user

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On Sat, Oct 01, 2005 at 07:05:57AM +0400, Alexey Tourbin wrote:
> dante-server	/usr/sbin/sockd	U	eval_user

А вот это страшно:

$ ldd -r /usr/sbin/sockd
        libwrap.so.0 => /lib/libwrap.so.0 (0x4001a000)
        libpam.so.0 => /lib/libpam.so.0 (0x40021000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4002e000)
        libcrypt.so.1 => /lib/i686/libcrypt.so.1 (0x40043000)
        libdl.so.2 => /lib/i686/libdl.so.2 (0x40076000)
        libc.so.6 => /lib/i686/libc.so.6 (0x4007a000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: eval_user     (/usr/sbin/sockd)
$ /usr/sbin/sockd -v
sockd: dante v1.1.14
$ LD_BIND_NOW=1 /usr/sbin/sockd -v
/usr/sbin/sockd: symbol lookup error: /usr/sbin/sockd: undefined symbol: eval_user
$

Не будет он такой работать, падать будет!! :-(

$ rpmsymver libwrap-7.6-alt5.i586.rpm libwrap-7.6-alt6.i586.rpm
--- libwrap-7.6-alt5.i586.rpm/lib/libwrap.so.0.sym	2005-10-01 17:20:47 +0400
+++ libwrap-7.6-alt6.i586.rpm/lib/libwrap.so.0.sym	2005-10-01 17:20:47 +0400
@@ -1,6 +1 @@
-A _DYNAMIC
-A _GLOBAL_OFFSET_TABLE_
-A __bss_start
-A _edata
-A _end
 B dry_run
@@ -17,4 +12,2 @@
 D unknown
-T _fini
-T _init
 T clean_exit
@@ -23,8 +16,3 @@
 T eval_hostaddr
-T eval_hostinfo
 T eval_hostname
-T eval_server
-T eval_user
-T fix_fgets
-T fix_getpeername
 T fix_options
@@ -32,3 +20,2 @@
 T hosts_ctl
-T my_strtok
 T percent_m
@@ -45,3 +32,2 @@
 T split_at
-T tcpd_jump
 T tcpd_warn
	OLD symbols
A _DYNAMIC
A _GLOBAL_OFFSET_TABLE_
A __bss_start
A _edata
A _end
T _fini
T _init
T eval_hostinfo
T eval_server
T eval_user
T fix_fgets
T fix_getpeername
T my_strtok
T tcpd_jump
$ rpm -q --lastchange libwrap
* Mon Aug 15 2005 Dmitry V. Levin <ldv@altlinux> 1:7.6-alt6
- Restricted list of global symbols exported by the library.
$

Разломал ты его, Дима.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Sat, Oct 01, 2005 at 07:05:57AM +0400, Alexey Tourbin wrote:
> fetchmail	/usr/bin/fetchmail	U	krb5_init_ets

И это тоже страшно.

$ fetchmail --version |head -1
This is fetchmail release 6.2.5+RPA+NTLM+SDPS+SSL+NLS
$ LD_BIND_NOW=1 fetchmail --version |head -1
fetchmail: symbol lookup error: fetchmail: undefined symbol: krb5_init_ets
$

$ rpmsymver libkrb5-1.3.1-alt5.i586.rpm libkrb5-1.4.1-alt1.i586.rpm |wc -l
746
$ rpmsymver libkrb5-1.3.1-alt5.i586.rpm libkrb5-1.4.1-alt1.i586.rpm |lsdiff
libkrb5-1.3.1-alt5.i586.rpm/lib/libdes425.so.3.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libgssapi_krb5.so.2.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libk5crypto.so.3.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libkadm5clnt.so.5.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libkadm5srv.so.5.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libkdb5.so.4.sym
libkrb5-1.3.1-alt5.i586.rpm/lib/libkrb5.so.3.sym
$ rpmsymver libkrb5-1.3.1-alt5.i586.rpm libkrb5-1.4.1-alt1.i586.rpm |grep krb5_init_ets |head -1
-T krb5_init_ets
$

Господа, на бочке с порохом сидим!  Если это у кого-то работает,
ему просто несказанно везёт.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: dante-server /usr/sbin/sockd U eval_user

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Sat, Oct 01, 2005 at 05:23:27PM +0400, Alexey Tourbin wrote:
> $ LD_BIND_NOW=1 /usr/sbin/sockd -v
> /usr/sbin/sockd: symbol lookup error: /usr/sbin/sockd: undefined symbol: eval_user

> $ rpm -q --lastchange libwrap
> * Mon Aug 15 2005 Dmitry V. Levin <ldv@altlinux> 1:7.6-alt6
> - Restricted list of global symbols exported by the library.

Да, и ещё вопрос на засыпку.  Сколько человек используют sockd и при
этом обновляются из сизифа?  Пользовательская база случайно выбранного
пакета стремится к нулю.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On Sat, Oct 01, 2005 at 05:38:55PM +0400, Alexey Tourbin wrote:
> On Sat, Oct 01, 2005 at 07:05:57AM +0400, Alexey Tourbin wrote:
> > fetchmail	/usr/bin/fetchmail	U	krb5_init_ets
> 
> И это тоже страшно.

Не вижу проблем, этот пакет (fetchmail) просто не собирается (см.
/raid/beehive/old-logs/2005/0701/error/fetchmail-6.2.5-alt1.1.1)
и место ему в orphaned.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Денис Смирнов]

On Sat, Oct 01, 2005 at 05:38:55PM +0400, Алексей Турбин wrote:

AT> $ LD_BIND_NOW=1 fetchmail --version |head -1
AT> Господа, на бочке с порохом сидим!  Если это у кого-то работает,
AT> ему просто несказанно везёт.

/me думает -- а может LD_BIND_NOW=1 куда-нибудь в /etc/profile.d на
Сизифе? В дистрибутивах так делать нельзя, а в сизифе будет правильнее
если по-умолчанию человек будет сразу видеть такие грабли.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Sat, Oct 01, 2005 at 09:33:11PM +0400, Денис Смирнов wrote:
> On Sat, Oct 01, 2005 at 05:38:55PM +0400, Алексей Турбин wrote:
> 
> AT> $ LD_BIND_NOW=1 fetchmail --version |head -1
> AT> Господа, на бочке с порохом сидим!  Если это у кого-то работает,
> AT> ему просто несказанно везёт.
> 
> /me думает -- а может LD_BIND_NOW=1 куда-нибудь в /etc/profile.d на
> Сизифе? В дистрибутивах так делать нельзя, а в сизифе будет правильнее
> если по-умолчанию человек будет сразу видеть такие грабли.

Не получится.  В частности, какие-то @#$%^& переписали новый xorg так,
что с LD_BIND_NOW=1 он в принципе не работает.  Там теперь драйверы и
прочие модули грузятся через dlopen(), но вместо нормальной линковки
список зависимостей извлекается из модуля уже после его загрузки (так
же, как делал их старый загрузчик, умевший грузить *.o и *.a), и через
тот же dlopen() загружаются требуемые модули.  Кстати, поиск и вывод
списка unresolved symbols, который там был при старом загрузчике
модулей, в результате они тоже потеряли.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Denis Smirnov]

Sergey Vlasov wrote:

>>/me думает -- а может LD_BIND_NOW=1 куда-нибудь в /etc/profile.d на
>>Сизифе? В дистрибутивах так делать нельзя, а в сизифе будет правильнее
>>если по-умолчанию человек будет сразу видеть такие грабли.
>>    
>>
>
>Не получится.  В частности, какие-то @#$%^& переписали новый xorg так,
>что с LD_BIND_NOW=1 он в принципе не работает.  Там теперь драйверы и
>прочие модули грузятся через dlopen(), но вместо нормальной линковки
>список зависимостей извлекается из модуля уже после его загрузки (так
>же, как делал их старый загрузчик, умевший грузить *.o и *.a), и через
>тот же dlopen() загружаются требуемые модули.  Кстати, поиск и вывод
>списка unresolved symbols, который там был при старом загрузчике
>модулей, в результате они тоже потеряли.
>  
>
Да... И насколько реально переписать этот код по-человечески?

[devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Sat, Oct 01, 2005 at 08:07:05PM +0400, Dmitry V. Levin wrote:
> Не вижу проблем, этот пакет (fetchmail) просто не собирается (см.
> /raid/beehive/old-logs/2005/0701/error/fetchmail-6.2.5-alt1.1.1)
> и место ему в orphaned.

i586-alt-linux-gcc -L/usr/lib  rcfile_y.o rcfile_l.o socket.o getpass.o pop2.o pop3.o imap.o etrn.o
odmr.o fetchmail.o idle.o env.o options.o daemon.o driver.o transact.o sink.o rfc822.o smtp.o xmalloc.o uid.o mxget.o md5ify.o cram.o kerberos.o gssapi.o opie.o rpa.o interface.o netrc.o base64.o report.o unmime.o conf.o checkalias.o smbdes.o smbencrypt.o smbmd4.o smbutil.o ipv6-connect.o lock.o md5c.o  -lcrypt  -lresolv -pipe -Wall -O2 -march=i586 -mcpu=i686 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lssl -lcrypto  -lfl -o fetchmail
driver.o(.text+0x1bb5): In function `do_session':
driver.c: undefined reference to `krb5_init_ets'
collect2: ld returned 1 exit status

Представляется, что проблема не в fetchmail, а в libkrb5.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Sun, Oct 02, 2005 at 05:18:51PM +0400, Alexey Tourbin wrote:
> On Sat, Oct 01, 2005 at 08:07:05PM +0400, Dmitry V. Levin wrote:
> > Не вижу проблем, этот пакет (fetchmail) просто не собирается (см.
> > /raid/beehive/old-logs/2005/0701/error/fetchmail-6.2.5-alt1.1.1)
> > и место ему в orphaned.
> 
> i586-alt-linux-gcc -L/usr/lib  rcfile_y.o rcfile_l.o socket.o getpass.o pop2.o pop3.o imap.o etrn.o
> odmr.o fetchmail.o idle.o env.o options.o daemon.o driver.o transact.o sink.o rfc822.o smtp.o xmalloc.o uid.o mxget.o md5ify.o cram.o kerberos.o gssapi.o opie.o rpa.o interface.o netrc.o base64.o report.o unmime.o conf.o checkalias.o smbdes.o smbencrypt.o smbmd4.o smbutil.o ipv6-connect.o lock.o md5c.o  -lcrypt  -lresolv -pipe -Wall -O2 -march=i586 -mcpu=i686 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lssl -lcrypto  -lfl -o fetchmail
> driver.o(.text+0x1bb5): In function `do_session':
> driver.c: undefined reference to `krb5_init_ets'
> collect2: ld returned 1 exit status
> 
> Представляется, что проблема не в fetchmail, а в libkrb5.

Я слышал, что libkrb5 изменился, а fetchmail отстал.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Sun, Oct 02, 2005 at 05:40:01PM +0400, Dmitry V. Levin wrote:
> > driver.c: undefined reference to `krb5_init_ets'
> > collect2: ld returned 1 exit status
> > Представляется, что проблема не в fetchmail, а в libkrb5.
> Я слышал, что libkrb5 изменился, а fetchmail отстал.

soname у libkrb5.so.3 не изменился, а fetchmail отстал, да. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Sun, Oct 02, 2005 at 07:04:00PM +0400, Alexey Tourbin wrote:
> On Sun, Oct 02, 2005 at 05:40:01PM +0400, Dmitry V. Levin wrote:
> > > driver.c: undefined reference to `krb5_init_ets'
> > > collect2: ld returned 1 exit status
> > > Представляется, что проблема не в fetchmail, а в libkrb5.
> > Я слышал, что libkrb5 изменился, а fetchmail отстал.
> 
> soname у libkrb5.so.3 не изменился, а fetchmail отстал, да. :)

Если бы я ещё использовал fetchmail, то я бы пересобрал его без krb5.
Пусть мантейнеры разбираются.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: dante-server /usr/sbin/sockd U eval_user

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 205 bytes --]

* Alexey Tourbin <at@> [051001 18:00]:
> Да, и ещё вопрос на засыпку.  Сколько человек используют sockd и при
Мы пытались пользоваться dante около года назад.  Не работает.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: dante-server /usr/sbin/sockd U eval_user

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Sun, Oct 02, 2005 at 08:16:45PM +0400, Alexey I. Froloff wrote:
> > Да, и ещё вопрос на засыпку.  Сколько человек используют sockd и при
> Мы пытались пользоваться dante около года назад.  Не работает.
Номер бага? :]]

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

А в чём проблема собрать то, что стало orphaned?
Или оно не работает?
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: dante-server /usr/sbin/sockd U eval_user

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

* Andrey Rahmatullin <wrar-alt@> [051002 20:37]:
> > > Да, и ещё вопрос на засыпку.  Сколько человек используют sockd и при
> > Мы пытались пользоваться dante около года назад.  Не работает.
> Номер бага? :]]
Для начала #4268.  Мне было проще сменить dante на squid чем
разбираться что именно там не работает...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:

 > On Sat, Oct 01, 2005 at 08:07:05PM +0400, Dmitry V. Levin wrote:
 >> Не вижу проблем, этот пакет (fetchmail) просто не собирается (см.
 >> /raid/beehive/old-logs/2005/0701/error/fetchmail-6.2.5-alt1.1.1)
 >> и место ему в orphaned.

http://lists.altlinux.ru/pipermail/devel/2005-July/022142.html

-- 

[devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[Michael Shigorin]

On Mon, Oct 03, 2005 at 01:18:39PM +0400, Sergey Bolshakov wrote:
>  >> и место ему в orphaned.
> http://lists.altlinux.ru/pipermail/devel/2005-July/022142.html
On Sun, Oct 02, 2005 at 07:15:21PM +0400, Dmitry V. Levin wrote:
> Если бы я ещё использовал fetchmail, то я бы пересобрал его без krb5.

А нафига козе баян?  В смысле этой функциональностью у нас вообще
кто-то пользуется?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: fetchmail /usr/bin/fetchmail U krb5_init_ets

[php-coder]

--- Michael Shigorin 2005-10-03 15:16:11 +0300
+++ php-coder 2005-10-03 23:36:01 +0700

MS> А нафига козе баян?  В смысле этой функциональностью у нас вообще
MS> кто-то пользуется?

    Даже если и пользуется (в чем я лично сомневаюсь), то нужно этот керберос
    отрезать как гангрену на теле fetchmail, иначе зараза расползется и
    вся программа уйдет в пучину orphaned-пакетов. И чем я тогда буду почту
    получать?! :)

    Голосую: отключить!

    P.S. Спасение утопающих, дело рук самих утопающих, так что у тех кто
    таки использует этот керберос есть чем заняться ;)

-- 
+ php-coder
+ php-coder[at]altlinux[dot]ru

Re: [devel] fetchmail /usr/bin/fetchmail U krb5_init_ets

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

В Сбт, 01/10/2005 в 20:07 +0400, Dmitry V. Levin пишет:
> On Sat, Oct 01, 2005 at 05:38:55PM +0400, Alexey Tourbin wrote:
> > On Sat, Oct 01, 2005 at 07:05:57AM +0400, Alexey Tourbin wrote:
> > > fetchmail	/usr/bin/fetchmail	U	krb5_init_ets
> > 
> > И это тоже страшно.
> 
> Не вижу проблем, этот пакет (fetchmail) просто не собирается (см.
> /raid/beehive/old-logs/2005/0701/error/fetchmail-6.2.5-alt1.1.1)
> и место ему в orphaned.

В Sisyphus ушел -alt2 с исправлением.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]